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ABSTRACT 

This  research  represents  a  preliininar\'  step  in  the  development  of  a  rehable 
application  program  simulating  an  operating  system  which  handles  several  miulti- 
security-level  users  dynamically  sharing  system  resources  in  the  Gemini  Trusted 
Multiple  Microcomputer  Base  machine. 

The  proposed  design  presents  the  necessary  steps  to  follow  when  working  in  a 
multilevel  configuration.  The  use  of  primitives  that  support  the  application  design 
are  explained  along  with  a  description  of  the  implementation  of  this  application 
using  Janus/Ada  language.  In  addition,  security  constraints  are  identified  and 
svstem  test  results  are  described. 
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I.    INTRODUCTION 

A.    GENERAL  DISCUSSION 

This  thesis  presents  the  design  and  part  of  the  implementation  of  software  for 
the  Gemini  Computer,  under  CP/M-86  and  GEMSOS  Operating  Systems,  to 
allow  the  dynamic  sharing  of  system  resources  in  a  multilevel  secure  computer 
system,  using  Janus/Ada  language  as  a  host  language. 

Security  has  traditionally  been  provided  by  physical  measures  (fences,  police, 
dogs,  alarms,  etc.)  to  prevent  unauthorized  access  to  computers.  But  today  this  is 
no  longer  sufficient.  The  extensive  use  of  networks  brings  the  possibility  of 
uncontrolled  access  to  the  resources  of  any  installation  from  remote  sites. 
Discretionary  security  measures,  i.e.,  "password"  types,  alone  are  not  totally 
adequate  where  security  of  information  is  paramount  [Ref.  l].  Steps  must  be 
taken  to  strictly  reinforce  a  non-discretionary  policy  as  well.  This  situation 
provides  enough  motivation  to  look  for  more  reliable  methods  to  control  and  limit 
the  access. 

This  necessity  of  Trusted  Computers  is  even  more  critical  and  compulsorj^  in 
military  organizations,  where  many  delicate  decisions  depend  on  the  quality  of  the 
information,  which  if  known  or  modifiable  by  unauthorized  users,  creates  a  risk  to 
the  countrv's  securitv. 
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The  Xaval  Postgraduate  School  is  involved  in  the  use  of  microcomputers  in 
its  Microcomiputer  Laboratory'  in  which  several  of  them  are  networked  together 
through  a  concentrator  for  information  sharing.  These  systems  are  to  be  used  by 
people  with  different  levels  of  security  clearance  who  handle  information  with 
multiple  security  classifications.  This  application  necessitates  the  use  of  a  mass 
storage  system  with  the  ability  to  limit  access  to  classified  programs  and  data. 
The  only  effective  way  to  insure  multi-level  internal  security  is  by  employing  a 
Trusted  Computer  Base  [Ref.  2]  such  as  provided  by  the  Gemini  computer. 

Figure  1.1  shows  the  proposed  configuration  of  a  microcomputer  system 
having  the  Gemini  computer  at  its  base.  The  Gemini  System  provides  the  base 
layer  of  an  operating  system  which  implements  internal  information  security 
through  a  "security  kernel"  design  [Ref.  3:pp.  1-2].  To  construct  the 
architecture  proposed  in  Figure  1.1  requires  implementing  the  top  layer  of  the 
operating  system  for  handling  the  Input/Output  operations.  Three  design 
elements  can  be  identified  : 

1)  The  Concentrator.  The  concentrator  will  contain  a  software  "crossbar 
switch"  which  allows  dynamic  switching  for  I/O  interconnection  between 
attached  systems. 

2)  The  Dynamic  Assignment  of  Security  Access  Levels  to  I/O  devices.  In  this 
aspect,  the  main  idea  is  to  manage  the  access  level  of  the  terminal  without 
relating  it  to  an  specific  connection.  The  access  level  should  be  dynamically 
recognized  by  the  characteristics  of  the  user,  rather  than  be  limited  to  a 
secondary-  issues  such  as  location  or  terminal  number.  This  is  the  main  topic 
addressed  by  the  current  research. 
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VAX  11/780 
UNIX 


Z-100 
Microcomputers 


Figure  1.1     Microcomputer  System  Organization 


3)  A  Segmented  "File"  System  for  Mass  Storage.  The  purpose  of  this  system 
would  be  to  provide  a  one-level  segmented  storage  system  for  mass  secondary 
storage  (hard  disk)  within  a  secure  environment. 


B.    THESIS  FORMAT 

This  thesis  is  composed  of  six  chapters  organized  in  such  a  way  as  to  provide 
the  reader  with  the  background  necessary  to  understand  internal  multilevel 
computer  security  concepts,  in  particular  dynamic  sharing  of  system  resources. 
Simple  guidelines  in  software  development  are  introduced  and  a  design  is 
presented  for  the  implementation  of  a  prototype  system  which  allows  several  users 
with  different  clearance  levels  to  share  system  resources. 

Chapter  I  provides  general  information  focusing  on  reasons  why  Multilevel 
Secure  Systems  are  important. 
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Chapter  II  addresses  the  background  necessary  to  understand  Multilevel 
Security  concepts  and  explains  the  Gemini  System  Architecture  and  possibilities. 

Chapter  III  provides  specific  information  related  to  the  steps  necessary  to 
produce  basic  application  programs  in  the  Gemini  System. 

Chapter  IV  describes  the  design  of  a  small  "Operating  System"  application 
program  that  will  handle  dynamic  sharing  of  resources,  in  particular  I/O. 

Chapter  V  presents  the  description  of  the  support  modules  used  to  develop 
application  programs,  and  describes  the  implementation  constraints  and  the  steps 
performed  to  complete  an  application. 

Chapter  "V'l  discusses  the  results  obtained  from  this  research  eff"ort.  It  also 
suggests  future  investigations  in  this  field  as  a  continuation  of  the  work  performed 
in  this  thesis. 
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II.    BACKGROUND 

A.    TRUSTED  COMPUTER  SYSTEM 

Most  of  the  basic  concepts  and  definitions  mentioned  in  this  section  are 
referenced  to  the  standardization  performed  by  the  Department  of  Defense  (DoD) 
related  to  Trusted  Computer  Systems.  These  standards  are  contained  in  "DoD 
Trusted  Computer  System  Evaluation  Criteria"  [Ref.  2]  published  in  1983;  it  lists 
definitions  and  concepts,  and  provides  detailed  criteria  pertaining  to  the  test  and 
evaluation  of  trusted  computers. 

The  security  policies  considered  are  mandatory  (non-discretionary)  security 
and  discretionary  security. 

Mandatory  Security  is  defined  as  : 

Security  Policies  defined  for  systems  that  are  used  to  process  classified  or 
other  specifically  categorized  sensitive  information  must  include  provisions 
for  the  enforcement  of  mandatory  access  control  rules.  That  is.  they  must 
include  a  set  of  rules  for  controlling  access  based  directly  on  a  comparison  of 
the  individual's  clearance  or  authorization  for  the  information  and  the 
classification  or  sensitivity  designation  of  physical  and  other  environmental 
factors  of  control.  The  mandatory  access  control  rules  must  accurately  reflect 
the  laws,  regulations,  and  general  policies  from  which  they  are  derived.  [Ref. 
2:p.  72] 


Discretionary  Security  is  defined  as  : 

Security  Policies  that  are  defined  for  systems  that  are  used  to  process 
classified  or  other  sensitive  information  must  include  provisions  for  the 
enforcement  of  the  discretionary  access  control  rules.  That  is,  they  must 
include  a    consistent  set  of  rules  for  controlling    and    limiting  access  based  on 
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identified  individuals  who  have  been  determined  to  have  a  Need-to- Know  for 
the  information.  [Ref.  2:p.  73] 

As  the  names  imply,  mandatory  policy  contains  a  set  of  rules  •  .at  are 
imposed  on  all  users  in  the  organization,  and  discretionary  policy  is  a  specific  set 
of  rules  further  limiting  access  on  a  "need-to-known"  basis. 

A  multilevel  secure  system  in  a  conventional  computer  system  is  impossible  to 
attain  without  a  way  to  enforce  the  policies  previously  indicated.  Security  can  be 
broken  without  knowledge  of  the  user  because  intentionally  or  not,  there  are 
possible  unsecure  points  that  will  allow  access  to  the  system.  A  typical  example  of 
this  problem  is  a  "Trojan  Horse"  program  [Ref.  4:p.  66]  provided  by  a  third 
source  which  may  have  code  intentionally  "hidden"  with  the  purpose  of  copying 
the  user's  access  control  code  [Ref.  5:pp.  55-56]  when  the  user  executes  the 
program.    This  represents  an  illegal  condition. 

The  mandatory  (non-discretionary)  and  discretionary  policies  are 
implemented  in  a  "security  kernel"  which  provides  mechanisms  for  limiting  the 
access  to  the  information.  Security  Kernel  is  defined  as  the  hardware  and 
software  that  realizes  the  "reference  monitor"  abstraction  (i.e..  the  realization  of 
these  limiting  policies),  and  in  turn  provides  the  idea  of  protection  in  which  the 
active  entities  (subjects),  such  as  people  or  computer  programs,  make  reference  to 
passive  entities  (objects),  such  as  documents  or  segments  of  memory,  using  a  set 
of  current  access  authorizations  [Ref.  6:p.  14].  The  access  class  is  divided  into 
[Ref.  6:p.  16]  : 
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a)  Compromise  (observe)  which  stares  that  a  subject  can  not  "observe"  the 
contents  of  an  object  unless  the  access  class  of  the  subject  is  greater  than  or 
equal  to  the  access  class  of  the  object. 

b)  Integrity  (modify)  which  stipulates  that  a  subject  may  not  "modify"  an 
object  unless  the  object's  access  class  is  greater  than  or  equal  to  the  access 
class  of  the  subject. 

The  multilevel  secure  system  considered  in  this  research  is  focused  on  the 
access  of  many  users  to  common  system  resources  without  restriction  of  a 
designated  resource  to  a  specific  kind  of  user.  Specifically,  any  user  can  utilize  any 
terminal,  and  the  access  class  in  not  limited  to  physical  terminals  with  fixed 
access  levels.  The  user  priviledges.  will  be  determined  during  a  logon  process  when 
the  user  provides  his  usemame  and  password. 

Additional  explanations  and  details  concerning  secure  communication 
methods  and  possible  threats  involved  are  described  in  [Ref.  7:pp.  15-28]  and  [Ref. 
8:pp.  19-21]. 

B.    GEMINI  TRUSTED  MULTIPLE  MICROCOMPUTER  BASE 
1.      General  Information 

Gemini  Trusted  Multiple  Microcomputer  Base  was  the  computer  used  in 
the  research  of  this  thesis.  It  represents  an  advance  in  technology  combining 
several  concepts.  Multilevel  Security,  Multiprocessing  and  Multiprogramming,  to 
provide  an  important  Trusted  Base  Machine  that  can  be  considered  for  a  wide 
range  of  computer  applications  where  security  is  a  fundamental  consideration. 
Actually,     it    has    been    evaluated    by    the    U.S.     Department    of    Defense    for 

15 


certification  to  meet   the   B3   class   [Ref.   3:pp.    1-2]..  and   is  currently  undergoing 
evaluation  in  a  specialized  application  for  Al  class. 

The  major  features  of  this  system  are  [Ref.  3]  : 

1)  Up  to  8  Intel  iAPX286-Base  microcomputers  are  connected  on  the  same 
Multibus. 

2)  Minimization  of  bus  contention  by  locating  data  and  code  segments  in  the 
local  memory  of  each  microcomputer,  whenever  possible. 

3)  Capability  of  multiprocessing  and  multiprogramming.  The  Gemini  Secure 
Operating  System  (GEMSOS)  can  multiplex  many  virtual  processors  onto  a 
single  physical  processor,  and  support  combinations  of  parallel  and  pipelined 
processing. 

4)  Connection  of  different  storage  and  I/O  devices  using  an  RS-232  Interface 
Board  which  can  handle  up  to  8  ports. 

5)  The  system  includes  a  Bus  Controller,  a  Real-Time  Clock,  a  Data  Encryption 
Device  (NBD-DES  Algorithm),  a  Non-volatile  Memory  for  storing  system 
passwords  and  encryption  keys.    It  also  provides  a  System- Unique  Identifier. 

6)  Each  iAPX286  microprocessor  supports  4  hierarchical  privilege  levels. 

7)  CP/M-86  Operating  System  is  used  for  software  development  and  several 
different  programming  languages  are  available  to  develop  application 
software. 

8)  Modular  Expansion  and  Configuration  Independence. 
2.     Resources  Management 

At  the  heart  of  the  Gemini  computer  system  is  the  GEMSOS  operating 

system  as  previously  mentioned. 

GEMSOS  resource  management  services  are  invoked  by  an  application 

program  through  a  set  of  calls  to  a  collection  of  subroutines  which  represent  an 
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interface  between  GEMSOS  and  the  application.  Each  language  compiler  has  a 
unique  interface  library"  [Ref.  3:p.  4].  GE\ISOS  manages  three  classes  of  entities  : 
segments,  processes,  and  devices. 

a.  Segment  Management 

All  the  information  is  stored  in  logical  objects  called  segments  which 
are  handled  by  the  application  programmer  using  segment  management  calls. 
These  operating  system  calls  are  described  in  detail  in  [Ref.  9:p.  10].  • 

b.  Process  Management 

A  process  can  be  viewed  as  an  application  program  that  runs  under 
the  control  of  GEMSOS  to  perform  some  specific  activity.  The  process  is  created 
by  the  application  program  using  service  calls  related  to  the  process  management 
described  in  [Ref.  3:pp.  5-8]  and  [Ref.  9:p.  23].  In  addition  to  Process 
Management,  there  are  additional  concepts  related  to  process  synchronization  in 
which  the  application  programmer  has  tools  to  sequence  processes  that 
communicate  with  each  other.  Synchronization  is  obtained  utilizing  eventcounts 
and  sequencers  [Ref.  10:pp.  115-124]  associated  with  processes.  A  working 
explanation  will  be  provided  in  Chapter  IV.  Process  Synchronization  calls  are 
described  in  detail  in  [Ref.  3:pp.  6-7]  and  [Ref.  9:p.  33]. 

c.  Device  Management 

The  design  of  the  I/O  management  functions  of  the  Kernel  are  novel. 

The  basic  idea  consists  of  reducing  the  code  needed  in  the  Kernel  to  control  I/O 

functions,  by  incorporating  many  of  the  details  within  the  application  program. 
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The    result    is    a    reduction    of   the    Kernel's    size    and    the    verification    is    easier. 
Security  checks  are  performed  only  when  the  device  is  attached  to  a  process  [Ref. 
3:pp.  8-9].  I/O  management  service  calls  are  described  in  [Ref.  ll:p.  38]. 
3.      Gemini  Security  Architecture 

Since  the  iAPX286  Microcomputer  supports  4  protection  levels,  GEMSOS 
uses  these  levels  to  enforce  the  security  critical  layering  of  the  system.  Protection 
levels  are  called  Ring  0  thru  Ring  3.  with  Ring  0  the  most  privileged  ring  [Ref.  3: 
p. 10].  Ring  0  supports  the  Mandatory  (non-discretionary)  Policy  and  Ring  1 
contains  the  Discretionary  Policy,  the  combination  of  which  comprising  the 
Security  Perimeter  and  the  greater  portion  of  GEMSOS. 

Ring  1  also  holds  functions  such  as  user  authentication,  system  security 
officer  functions  and  audit  functions.  Ring  2  is  used  for  common  services  utilized 
by  many  users,  e.g.,  Database  Management  Systemi:  Ring  3  is  used  as  application 
layers  for  programs  and  data:  both  are  outside  of  the  Security  Perimeter  and  can 
be  used  during  the  system  development  process  (i.e.,  as  in  developing  the  upper 
layer  of  an  application  system  as  is  the  focus  of  this  research),  and  for  the 
execution  environment  for  user's  programs. 

Process  management  in  the  GEMSOS  architecture  is  through  the  use  of  a 
two  level  traffic  controller  design  (inner  traffic  controller  or  bottom  level,  and 
upper  traffic  controller). 

The  inner  traffic  controller  binds  a  physical  processor  with  a  fixed  number 

of  "virtual  processors".  Two  of  these  are  used  to  support  system  services  (an  idle 
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virtual  processor  and  a  manager  virtual  processor)  and  the  others  are  available  to 
the  upper  level  traffic  controller.  The  inner  traffic  controller  also  provides  the 
primitives  for  synchronization  between  virtual  processors  emulating  a 
multiprogramming  configuration. 

The  upper  level  traffic  controller  multiplexes  a  number  of  processes  onto 
the  virtual  processors  defined  by  the  inner  traffic  controller.    These  functions  are 
performed  in  each  of  the  physical  processors  comprising  the  Gemini  computer  (up 
to  8)  [Ref.  7:pp.  14-15].  through  a  distributed  operating  system. 
4.     Naval  Postgraduate  School  Version  of  Gemini 

a.  One  APX286  Microcomputer 

b.  Two  1.2  Mbyte  floppy  disk  drives 

c.  One  RS-232  Interface  Board  (max  8  ports) 

With  this  configuration,  GEMSOS  must  multiplex  the  processes  created 
onto  virtual  processors  and  then  onto  a  single  physical  processor.  The 
synchronization  primitives  support  the  communication  among  processes.  It  is 
important  to  note  that  in  this  configuration,  a  multiprocessing  environment  does 
not  exist.  The  potential  for  exploiting  processor  parallelism  does  not  exist. 
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III.    SOFTWARE  DEVELOPMENT  OVERVIEW 

A.    GENERAL  DESCRIPTION 

This  chapter  provides  the  foundation  for  the  necessary  steps  to  develop 
software  in  Gemini  machines.  It  is  important  because  it  provides  the  basic 
components  that  are  needed.  Considering  that  Gemini  is  a  new  concept  in 
Multilevel  Secure  machines,  it  is  still  not  user  friendly.  A  bridge  between  the 
application  programmer  and  the  operating  system  ser\'ice  primitives  had  to  be 
created  in  order  to  develop  reliable  software. 

The  basic  Gemini  operating  system  is  limited  and  only  supports  those 
operating  system  functions  which  are  concerned  with  system  security.  Thus,  only 
an  operating  system  base  is  provided  upon  which  an  upper  level  i.e.,  I/O  handler, 
file  manager,  etc.    must  be  provided  to  support  specific  user  requirements. 

Subroutines  or  modules  were  prepared  to  perform  the  interface  between  the 
programmer  and  the  operating  system  primitives.  A  complete  explanation  of 
these  modules  is  provided  in  the  design  and  implementation  chapters. 

The  objective  of  this  chapter  is  to  present  an  ordered  method  of  developing 
application  software  within  the  environment.  It  should  be  considered  as  a  guide 
and  not  as  a  fixed  set  of  rules.  The  facts  considered  here  are  taken  from  the  user's 
manual  [Ref.  9]. 
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B.    HIERARCHICAL  STORAGE  STRUCTURE 

The  Gemini  System  provides  a  one-level  secondan,-  storage  system  for 
information  (In  the  NFS  configuration.  secondar\^  storage  refers  to  floppy  disks). 
File  concepts  are  not  supported  by  Gemini,  but  instead  segments  are  used  which 
are  considered  as  objects  having  logical  attributes  related  to  them  (i.e..  security) 
and  being  of  a  maximum  64  K  bytes  size.  Segmentation  is  extended  to  secondary' 
storage,  providing  the  one-level  storage  system. 

The  segments  are  handled  by  the  system  as  a  hierarchy,  where  each  segment 
is  identified  by  a  unique  path  name.  This  segment's  "handle"  corresponds  to  the 
index  of  an  entry  in  the  Local  Description  Table  (LDT)  of  the  process  that  creates 
and/or  uses  the  segment.  As  such,  a  single  segment  can  have  many  diff"erent 
handles  depending  on  where  and  how  many  processes  enter  it  into  their  respective 
LDT  tables.    But  it  has  only  one  unique  path  name  in  the  hierarchy. 

The  representation  of  segments  follow  a  hierarchical  structure  in  which  the 
root  is  the  System  Root  (transparent  to  the  user)  and  the  whole  collection  of 
segments  is  assembled  as  an  inverted  tree.  Each  user's  program  is  part  of  the 
hierarchical  structure  and  it  is  declared  as  a  segment  that  is  statically  created  at 
system  generation  time  using  the  Sysgen  Submit  file  explained  in  [Ref.  ll:pp.  12- 
14]. 

System  generation  consists  of  creating  a  hierarchical  structure  of  all  segments 

known  to  the  system  at  system  runtime,  in  particular  at  system  "Bootload".  It 

basically  is  the  inclusion  of  the  segment  hierarchy  comprising  the  upper  levels  of 
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the  application  target  system,  into  the  provided  base  level  hierarchy  that  is  known 
as  GEMSOS.  This  is  accomplished  by  utilizing  segments  declared  in  the  submit 
file,  i.e.,  the  sysgening  process  creates  a  hierarchy  using  the  segments  indicated  in 
the  submit  file. 

Figure  3.1  shows  a  typical  hierarchical  structure  representing  the  entries  that 
GEMSOS  requires  to  run  programs.  This  structure  is  fixed  and  m.ust  be 
considered  in  the  development  of  any  application  program.  Figure  3.2  shows  the 
addition  of  segments  necessary  to  execute  a  specific  application.  Entry  5  in  the 
hierarchical  structure  is  always  dedicated  as  the  "root"  of  user  application^.  This 
entry  is  the  root  or  mentor  of  all  the  segments  that  are  needed  to  implement  the 
upper  levels  of  the  system  application  program.  Under  the  Gemini  concept,  a 
segment  can  support  up  to  12  descendants  (entries)  numbered  from  0  thru  11.    To 
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Figure  3.1    Hierarchical  Structure 
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support  this  concept  there  is  an. "aliasing"  table  that  relates  the  segments  to  their 
mentors;  a  segment  can  only  have  one  mentor  [Ref.  ll:p.  l]. 

When  an  entry  is  used,  it  cannot  be  assigned  again  until  a  delete  segment  call 
marks  this  segment  as  available.  The  numbers  indicated  in  both  figures 
correspond  to  entry  numbers  of  segments  associated  with  a  mentor  (from  0  thru 
11);  segment  numbers  have  a  different  enumeration,  which  correspond  to  their 
entries  in  the  LDT. 

Each  segment  in  the  system  has  a  unique  pathname  that  identifies  it,  but  this 
identifier  is  not  used  by  the  application  processes.  Instead  a  process-local  segment 
number  is  used.  When  two  processes  share  the  same  segment,  each  one  recognizes 
the  segment  bv  the  number  assigned  in  its  own  LDT. 
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Figure  3.2    Hierarchical  Structure  including  an  application 
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In  Figure  3.2  the  path  5.7  corresponds  to  a  segment  that  holds  the  code  of  a 
child  appHcation  program  and  must  be  declared  in  the  Submit  file.  Entry  5  is  the 
mentor  of  Entry  7.  This  creation  is  static  and  the  path  indicated  must  be  known 
in  the  application  program.  On  the  other  hand,  the  path  5,5,7  is  used  to  hold  data 
and  will  be  created  dynamically  during  execution  of  the  application  program.  A 
more  complete  explanation  is  presented  later  in  this  chapter  and  in  Chapter  lY. 

C.  I/O  DEVICE  ASSIGNMENT 

The  process  of  "Attaching  Devices"  must  be  accomplished  before  an  I/O 
device  becomes  "known"  to  the  system.  It  involves  assigning  a  logical  process  to 
the  I/O  device  so  that  the  device  then  is  known  by  its  process.  The  process  then 
contains  the  device  drivers.  This  step  is  necessary  before  any  I/O  operation.  A 
device  can  be  declared  either  as  a  Read  (input)  or  Write  (output)  device,  as  part 
of  the  information  provided  to  the  Attach  primitive  call  into  GEMSOS  [Ref. 
9:pp.  39-41].  A  device  can  be  attached  to  only  one  process  at  a  time,  an  error  will 
occur  if  an  attempt  is  made  to  attach  a  device  more  than  one  time. 

The  inverse  step  is  called  Detach  devices,  in  which  the  associated  process  is 
eliminated  and  the  device  becomes  available  for  further  assignments  [Ref.  9:p.  42]. 

D.  PROCESS  CREATION 

This  section  describes  the  steps  that  should  be  considered  when  creating  a 

process.    One  process  is  created  from  another.  The  "creator"  process  is  known  as 

the  parent   and  the  created  process  is  known  as  the  child,  also  having  its  own 
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unique  identifier.  The  child  process  receives  its  fixed  amount  of  resources  from  the 
parent,  subtracting  from  the  parent's  overall  resources.  A  process  is  a  collection 
of  segments  known  to  the  process.  The  segments  are  managed  using  a  set  of 
primitive  functions  or  "calls"  provided  by  the  system.  An  address  space  is  created 
to  hold  a  segnaent.  The  application  programmer  must  make  use  of  GEMSOS 
primitives  in  creating  and  using  this  address  space. 

The  sequence  of  steps  that  must  be  followed  in  order  to  create  a  process, 
starts  with  the  creation  of  a  segment  in  the  address  space  using  the  resources 
available  on  secondarv'  storage.  The  primitive  create  is  called,  resulting  in  the 
creation  of  the  address  space  for  this  segment.  The  next  step  links  the  space 
created  with  a  specific  process  that  will  use  it.  In  other  words,  a  recognition  of  this 
segment  is  performed  in  which  the  process  makes  the  segment  known  to  itself  by 
entering  it  in  the  next  available  entry  in  its  local  description  table  (LDT).  The 
result  is  the  identification  of  this  address  space  by  a  number  that  is  called 
segment  number  which  will  be  used  when  the  segment  is  referenced.  The 
primitive  used  is  makeknown.  The  result  is  the  identification  of  this  segment  for 
the  process  and  to  the  system. 

The  last  step  is  related  to  the  utilization  of  this  segment;  a  segment  must  be 
in  main  memory  in  order  to  be  used.  This  function  is  performed  using  the 
primitive  swap-in,  which  produces  the  loading  of  the  segment  from  secondary 
storage  into  main  memory. 
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When  the  segment  is  no  longer  needed  by  the  process,  i.e..  process  completed 
execution,  an  inverse  action  must  be  performed  in  order  to  release  the  space  used 
by  the  segment.  As  in  the  steps  declared  above,  a  logical  sequencing  must  be 
followed,  starting  with  the  release  of  the  memory  used  by  the  segment.  This  is 
performed  by  the  s"Nvap-out  primitive  in  which  the  segment  is  written  back  out 
to  secondary'  storage.  The  next  step  is  the  elimination  of  the  association 
segment-process.  Elimination  of  a  segment  from  a  process'  address  space  is 
performed  by  the  terminate  primitive;  the  association  is  broken,  and  the  entry 
number  used  in  the  LDT  of  that  process  is  available  again. 

The  total  removal  of  a  segment  from  the  system  address  space  is 
accomplished  by  using  the  delete  primitive;  the  result  is  the  removal  of  the 
segment  from  the  system  and  process  local  name  space,  and  the  returning  of  its 
address  space  back  to  the  system  resources.  The  steps  necessary  to  create  a 
process  are  indicated  in  the  Figure  3.3. 

1.     Create  /  Makeknown  Segments  Module 

A  process  needs  a  minimum  of  two  segments,  a  code  segment  and  a  stack 

segment,  in  order  to  be  created.  The  code  segment  for  a  process  is  declared  in  the 

Sysgening   Submit   file   and   is  created  automatically  by  the  system  during  the 

system  generation  (statically). 

The  stack  segment,  as  well  as  any  additional  segments,  are  created  in  the 

user's  program  (dynamically)  by  making  the  appropiate  operating  system  calls  for 

Create  and  Makeknown.    These  calls  will  be  explained  later  in  this  chapter. 
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Figure  3.3    Process  Creation  Main  Modules 


2.     Address  Space  Specification  Module 

The  address  space  specification  contains  a  list  of  the  segments  that  will  be 
passed  by  the  parent  process  to  the  new  process  (child).  In  addition,  the  attributes 
of  each  segment  to  be  passed  are  loaded  into  this  module.  The  address  space 
specification  of  a  process  is  composed  of  5  segments  :  a  stack  segment,  a  code 
segment  (both  are  compulsor}'),  2  free  segments  (can  be  used  as  application 
mentor  and  for  holding  data)  and  a  trap  segment  that  is  automatically  created  (it 
is  declared  in  the  submit  file)  and  handled  by  the  system.  It  holds  information  for 
GEMSOS  that  will  be  used  when  a  user  trap  fault  is  detected.  These  segments 
correspond  to  entries  20  thru  24  of  the  Local  Description  Table  to  be  associated 
with  each  process. 
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3.  Register  Record  Module 

This  module  performs  the  initialization  of  the  register  record  which 
defines  the  state  in  which  the  program  will  begin  its  execution.  The  register 
record  contains  the  following  fields  [Ref.  9:p.  27]  : 

1)  Instruction  pointer  (ip)  .-  Specifies  the  code  offset  address.    • 

2)  Stack  pointers  : 

-  SP    .-  The  initial  stack  pointer  for  the  new  process. 

-  SPl  .-  Points  to  the  base  of  the  ring  1  stack  segment. 

-  SP2  .-  Points  to  the  base  of  the  ring  2  stack  segment 

(if  one  is  used). 

4.  Resource  Record  Module 

In  this  module  the  new  process  (child)  attributes  are  declared,  and  the 
amount  of  resources  that  the  parent  process  will  have  to  provide  to  the  new 
process  are  defined  [Ref.  9:pp.  27-28].  The  resources  received  by  the  child  process 
are  subtracted  from  those  of  the  parent.  The  amount  of  resources  needed  by  a 
child  will  depend  of  the  kind  of  application  that  a  child  will  perform.  The 
resources  involved  are  [Ref.  9:pp.  27-28]  : 

-  Amount  of  memory  (blocks)  that  the  child  is  allowed  to  swapin. 

-  Maximum  number  of  processes  that  the  child  is  allowed  to  create. 

-  Total  number  of  segments  that  the  child  will  have. 

In  addition  to  the  resources,  a  child  process  number  must  be  declared  that 
uniquely  indentifies  this  child.  Also  the  child's  access  class  must  be  specified  which 
must  be  within  the  parent's  range.  The  resources  passed  to  the  child  process  are 
recovered  by  the  parent  when  the  child  finishes  its  execution  and  self  deletes. 
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5.     Create  Process  Module 

The  primitive  Create  Process  is  called,  resulting  in  a  new  process  being 
created.  A  success  code  is  returned  by  the  operating  system  to  indicate  success  or 
failure  for  this  operation.  The  parameters  passed  by  this  module  are  the  record 
description  of  the  process  to  be  created  (rl  cp  struct)  and  a  variable  called 
"success"  that  will  hold  the  execution's  result  of  this  primitive.  The  application 
programmer  must  fill  all  the  fields  related  to  the  characteristics,  attributes  and 
resources  that  the  new  process  will  have.  A  description  of  the  record 
"rl  cp  struct"  is  given  in  the  library-  AGATE. LIB  provided  by  Gemini 
Computers  Inc..  and  in  [Ref.  9:pp.  24-28].  Error  codes  are  explained  in  [Ref.  9:pp. 
84-93].  All  the  modules  described  above  can  be  executed  in  any  order  before  the 
execution  of  this  module. 

E.    LOCAL  DESCRIPTION  TABLE  (LDT) 

Since  the  actual  use  of  the  GEMSOS  primitives  requires  interfacing  to  the 
upper  level  of  the  application  system  under  development,  special  interface 
routines  had  to  be  implemented.  The  next  three  sections  describe  these  interface 
routines.  A  process  has  a  fixed  collection  of  segments  which  comprisess  its  address 
space;  these  are  known  by  the  process  as  entries  in  its  Local  Description  Table 
(LDT).  Each  process  can  have  up  to  52  segments  (from  0  thru  51)  known  to  it  at 
one  time.  Segments  0  to  19  are  used  by  the  Kernel,  segments  20-24  correspond  to 
segments  pre-defined  in  the  address  space  definition  of  the  new  process  [Ref.  9:pp. 
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26-27].  and  segments  25  through  51  are  available  to  the  application  programmer. 
This  segment  distribution  is  fixed  in  the  LDT  and  can  not  be  modified.  A  fatal 
error  will  result  if  a  system  segment  is  used  for  other  purposes  (segments  0  thru 
24). 

F.  CREATE/DELETE  SEGMENT 

Because  a  process  is  a  collection  of  segments,  segment  creation  is  an 
important  step  that  should  be  considered  during  process  creation.  Each  segment 
has  its  own  attributes  which  are  specified  in  a  Create  seg  struc  record:  this 
record  must  be  declared  before  calling  the  primitive  Create_segment.  The 
segment  is  created  with  the  specified  attibutes,  and  the  addition  of  a  new  branch 
in  the  hierarchical  structure  is  made  [Ref.  9:pp.  14-15].  The  inverse  action  is  the 
Delete  segment  call,  where  a  segment  created  previously  is  removed  from  the 
hierarchical  structure,  this  call  should  be  performed  when  the  specified  segment  is 
no  longer  needed  [Ref.  9:pp.  16-17].  This  call  must  be  used  when  a  process 
finishes  its  execution  because  the  applicable  segments  are  not  automatically 
removed. 

G.  MAKEKNOVVN/TERMINATE  SEGMENT 

The  Makeknown    segment  call  adds  the  specified  segment  to  the  address 

space  of  the  calling  process  (including  the  segment  number  in  its  LDT  table)  [Ref. 

9:pp.   17-19].  Like  all  the  primitives  it  has  its  own  record  Mk_kn_structure, 

which  must  be  initialized  with  the  pathname  that  the  segment  will  use  in  the 
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hierarchical  structure.  Complete  details  are  provided  in  Chapter  I\ .  The  inverse 
step  eliminates  the  pathname  created  in  the  makeknown  process  and  also  frees  the 
segment  number  from  the  LDT  table.  This  primitive  is  Terminate  segment 
and  it  is  described  in  [Ref.  9:p.  20]. 

H.    SWAPIN/SWAPOUT  SEGMENT  ' 

A  segment  is  created  in  secondary*  storage  by  first  utilizing  the  primitive 
Swapin  segment,  to  provide  main  memory  space  for  the  new  segment,  and  the 
writing  the  new  segment  out  to  secondar}-  '  storage  by  utilizing 
Swapout  segment  primitive.  This  function  call  writes  any  segment  currently 
stored  in  main  memory  out  to  secondary-  storage  [Ref.  9:pp.  21-22].  releasing  the 
main  memory. 

I.      SYNCHRONIZATION 

Synchronization  among  processes  is  maintained  by  the  use  of  eventcounts  and 
sequencers  [Ref.  10. pp.  115-124].  which  are  maintained  in  segments  used  to 
synchronize  processes.  The  segments  used  must  be  common  to  all  the  processes 
involved  in  the  same  synchronization.  An  eventcount  is  maintained  by  an  integer 
counter  under  control  of  the  cooperating  process.  Completion  of  an  operation 
(event)  is  signaled  by  incrementing  the  eventcount.  The  updated  eventcount 
provides  a  signal  to  a  waiting  process  that  the  operation  which  it  has  been  waiting 
for  is  complete.    The  primitives  used  are  described  in  [Ref.  9:pp.  33-37]. 
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IV.   SYSTEM  DESIGN 

A.    INITIAL  DESIGN 

1.  Objective 

The  initial  objective  of  the  design  was  to  build  the  upper  levels  of  an 
operating  system  based  on  the  Kernel  provided  by  GEMSOS,  which  would 
provide  multiuser  mass  secondary-  storage  capability,  in  a  multilevel,  secure 
internal  environment.  User  access  through  terminals  was  initially  to  be  without 
physical  security  barriers,  and  terminal  access  levels  determined  dynamically 
based  on  user  access  levels.  I/O  device  ser\'icing  was  to  be  interrupt  driven. 
Figure  4.1  shows  the  initial  design  containing  3  main  modules  that  compose  the 
upper  levels  operating  system  :  Basic  Input/Output  (BIOS).  Console  Command 
Processor  (CCP).  and  Basic  Disk  Operating  System  (BDOS).  Implementation  of 
these  modules  duplicates  the  same  organization  used  in  CP/M  or  DOS  Operating 
Systems.  Secondary  storage  is  to  be  by  segments,  providing  a  "one  level"  storage 
system,  i.e.,  no  file  concept.  Security  is  provided  by  the  GEMSOS  operating 
system. 

2.  Initial  Design  Constraints 

One  major  limitation  to  the  above  design  was  the  restricted  way  in  which 
GEMSOS  handles  interrupts.  I/O  interrupt  handlers  currently  can  not  be  used 
from  ring  2  or  3  levels,  and  as  such  can  not  be  developed  in  the  BIOS  module. 
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Figure  4.1     Initial  Design 


Future  versions  of  GEMSOS  from  Gemini  Computers  Inc.  will  resolve  this 
constraint,  but  the  efforts  in  this  thesis  were  restricted  to  programmed  I/O  type  of 
device  handling. 

The  second  limitation  was  related  to  the  number  of  users  that  the  BIOS 
module  can  handle.  Since  the  communications  are  performed  through  a  RS-232 
interface  board  with  8  ports,  and  each  user  needs  one  physical  port  (read/write), 
the  maximum  number  of  users  is  8  (without  considering  a  device  for  the  main 
application  program).  This  limitation  still  exists  in  the  Naval  Postgraduate  School 
system  configuration. 
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B.    COMPROMISE  DESIGN 

1.  Objective 

The  primary  objective  is  the  same  as  declared  in  the  initial  design,  except 
that  the  BIOS  module  is  replaced  by  a  dedicated  program  to  handle  each 
terminal,  instead  of  several  terminals  handled  by  one  program.  Each  of  the 
programs  are  identical  routines  which  operate  at  a  System  high  access  level  to 
identify  a  new  user  through  the  terminal,  and  create  a  corresponding  access  level 
process  to  which  the  terminal  is  then  "attached".  Figure  4.2  shows  the  actual 
design  used. 

With  this  design.  Gemini's  capabilities  of  multiprocessing  can  also  be 
taken  advantage  of.  Each  user  can  have  a  virtual  processor  attached  to  itself  and 
work  in  a  multiprogramming  configuration,  limited  only  by  the  resources  available 
(processes,  segments,  memory,  ports,  etc.).  Considering  the  XPS  system,  it  is 
possible  to  emulate  multiprocessing  with  a  single  processor  in  which  GEMSOS 
multiplexes  the  processes  using  synchronization  methods.  The  distribution  of  the 
system  resources  among  individual  users  can  be  dynamically  assigned/reassigned 
based  on  the  needs  of  the  user.  The  amount  of  resources  assigned  to  the  users 
must  not  be  greater  than  the  resources  that  the  complete  system  has. 

2.  Actual  Design  Constraints 

As  previously  mentioned,  the  number  of  users  is  limited  to  8  because  of 
the  NFS  system  configuration. 
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Figure  4.2    Actual  Design 


The  second  limitation  is  related  to  the  size  of  the  LDT,  i.e..  the  number 
of  entries  that  the  apphcation  programmer  is  able  to  use.  If  a  process  nominally 
needs  3  segments  (stack,  code,  and  data)  this  means  that  not  more  than  9 
processes  can  be  created  in  the  main  application  program.  Considering  the  actual 
design  in  which  a  process  creates  another  process,  it  means  that  for  each  user 
process  six  segments  are  needed.  Since  there  are  only  27  segments  available  in  the 
LDT  for  each  process,  then  the  maximun  number  of  processes  is  4  (3  users  and 
the  BDOS  process).  By  including  the  data  segment  in  the  stack  segment,  only  4 
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segments  are  needed  for  each  process,  the  result  is  a  maximun  of  5  users  and  the 
BDOS  process. 

An  additional  limitation  comes  from  the  fact  that  there  are  no  developed 
modules  to  handle  the  hierarchical  structure  or  to  handle  the  LDT  table  of  each 
process.  This  means  that  the  next  available  entry  or  segment  number  in  the  LDT 
or  the  next  entry  related  to  a  segment  mentor  are  not  dynamically  provided  by 
the  system  and  must  be  obtained  in  some  way.  Instead  of  designing  and 
implementing  these  modules,  temporary'  modules  were  designed  to  create 
parameters  that  were  useful  to  the  system.  A  complete  set  of  modules  was 
provided  by  Gemini  Computers  Inc.  when  the  system  was  delivered,  but  these 
were  coded  in  Pascal  MT+  and  the  implementation  language  for  this  research  was 
Janus/Ada.  Conversion  from  Pascal  MT+  to  Janus/Ada  was  one  alternative  but 
there  was  no  documentation  of  the  function  and  structure  of  these  modules 
resulting  in  the  creation  of  parameters  instead  of  conversion. 

These  temporarj'  modules  create  parameters  statically  for  those  that  the 
system  should  provide  automatically.  Using  these  temporan'  modules  it  is  possible 
to  evaluate  system  functions  and  observe  how  the  the  hierarchical  structure  is 
m.aintained. 

3.      Hierarchical  Structure  Design 

Figure  4.3  shows  the  complete  structure  design  of  the  system,  considering 

the  segments  needed  to  work  with  3  users.    The  num.bers  indicated  inside  the 

circle  represent  an  entry  number  in  the  mentor's  LDT  (maximum  12  segments). 
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Figure  4.3    System  :  Hierarchical  Structure 


and  the  numbers  shown  outside  the  circle  represent  the  process-local  segment 
numbers  of  the  CCP  application  program.  They  are  used  to  identify  each 
segment.  This  can  be  seen  in  Figure  4.4.  The  hierarchy  shows  the  segments 
33,35,37,39  as  segments  that  hold  the  code  developed  to  support  the  application 
program  in  each  specific  level  :  User  Handler  processes  and  the  BDOS  process. 
These  segments  are  specified  in  the  Submit  file  and  are  created  in  the  sysgening 
process  together  with  those  segments  needed  to  hold  the  code  of  the  three  Active 
Users  processes.  The  segments  32,34,36,38  are  used  to  hold  the  stack  segments, 
and  the  segments  40,41,42,43  are  used  to  pass  information  between  processes. 
The  segment  51  is  used  by  CCP  to  eff'ect  synchronization  with  the  other  processes. 


37 


ntry\ 

uaer 

hdlr  1 

user 

hndlr  2 

user 

hdlr  3 

bdoa 
process 

uaer 
apple . 1 

uaer 
apple . 2 

uaer 

apple . 3 

segment 
name 

0 

32 

34 

36 

38 

45 

47 

4S 

STACK 

1 

33 

35 

37 

39 

— 

— 

— 

CODE 

2 

51 

51 

51 

51 

51 

51 

51 

SYNamONIZAT. 

3 

40 

41 

42 

43 

46 

48 

50 

DATA 

4 

— 

— 

— 

— 

— 

— 

— 

TRAP 

Figure  4.4    Address  Space  Specification  for  each  user  process 


awaiting  the  eventcount  of  this  segment  until  some  other  process  advances  it, 
thereby  letting  the  CCP  execute  its  functions. 
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Figure  4.5    Hierarchical  Structure  :  User  Processes 
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A  unique  pathname  identifies  each  segment  in  the  hierarchical  structure. 
An  example  of  this  concept  is  shown  in  Figure  4.5.  This  tree  represents  the  user 
handler  application  code  segments  and  their  segment  numbers  in  each  process. 

Although  the  segment  numbers  are  the  same  (32,33,34),  they  differ  by  the 
pathname  associated  with  them,  i.e.,  pathname  5.7,3.1  (userl)  pathname  5,8,3.1 
(user2),  and  pathname  5,9,3,1  (user3). 

C.    SYSTEM  SOFTWARE  DESIGN 

1.     Application  Programs  Design 

The  design  was  divided  into  2  types  of  programs,  applicative  programs 
(Main  Application  program  CCP.  User  Handler  program.  Active  User  application 
program,  and  BDOS  application  program)  and  utility  programs  (common 
procedures  and  functions).  Structured  programming  techniques  were  used  to 
develop  the  application  programs.  These  techniques  are  well  supported  by  the 
implementation  language  selected.  Janus/Ada.  Figure  4.6  shows  the  modules 
supporting  the  Main  Application  program  (CCP)  that  are  used  to  manage  the 
whole  system. 

These  modules  are  : 


Load  parameters 
Create  segments 
Create  processes 
Synchronize  processes 
Delete  Processes 
Terminate  segments 
Delete  segments 
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Figure  4.6    Main  Application  Program 


Each  module  was  developed  as  an  independent  procedure  or  function, 
requiring,  in  some  cases,  additional  subdivisions  because  of  the  high  complexity  of 
the  module.  These  modules  represent  upper  level  interfaces  to  GEMS  OS  system 
calls. 

a.  Load  Parameters  Module 

Figure  4.7  shows  the  table  of  parameters  created  by  this  module.  In 
addition  it  creates  another  table  with  segment  numbers  that  will  be  used  to 
synchronize  the  main  application  program  (CCP)  with  the  Active  User  programs. 

b.  Create  Segments  Module 

This  module  creates  the  segments  necessary  either  to  represent  some 
part  of  the  hierarchical  structure  or  to  perform  synchronization  among  processes. 
The  size  of  these  segments  is  fixed  (1  byte)  because  they  only  function  as  mentors 
of  other  segments  or  as  synchronization  segments.  A  synchronization  segment  is 
created  as  a  common  segment,  which  must  be  known  for  all  the  processes  in  the 
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Figure  4.7    System  Parameters 


application  program.  This  is  necessary  because  the  execution  of  the  main  module 
CCP  must  be  accessible  to  all  processes  communicating  with  the  CCP  to  perform 
some  operation. 

The  segments  created  are  : 


1)    Function 

Mentor 

Entry 

Classif 

Number 


mentor  of  stack  and  data  segments 
of  the  User  Handler  processes 
initial  segment  (2)  system  segment 
5 
unclassified 


31 


2)    Function  :    synchronization 

Mentor      :    segment  31  (created  previously) 
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Entry 

:    11 

Classif 

:    top-secret 

Number 

:    51 

c.  Create  Process  Module 

This  module  contains  a  loop  that  is  executed  4  times  which  creates 
three  User  Handler  processes  (3)  and  the  BDOS  process.  All  of  these  processes  will 
have  multilevel  access  classes  to  handle  users  with  different  levels  of  clearance. 

This  module  is  sub-divided  into  sub-modules  that  are  easier  to  test 
and  understand.  The  sub-modules  are  : 

1)  Create  and  Makeknown  segments 

2)  Fill  the  Address  Specification 

3)  Initialize  the  Register  record 

4)  Fill  the  Resource  record 

An  explanation  of  each  module  was  provided  in  Chapter  III.  The 
main  point  here  is  that  the  process  will  be  created  using  the  paramenters  loaded 
previously  and  each  process  will  receive  the  following  resources  : 

Memory     :    100  bytes 

Segments    :    300  segments  available 

Process        :    1  (max  number  of  processes  that  can  create) 

d.  Synchronization  Module 

The  synchronization  used  can  be  cataloged  in  one  of  four  types  : 

1)    Main  Application  Program-User  Handler  Process.    This  is  performed  in  two 
ways  : 

-  After  process  creation  the  User  Handler  Process  communicates  that  it  was 
created  and  returns  control  to  CCP. 
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-  During  process  synchronization  the  User  Handler  Process  will    communicate 
to  CCP  that  a  User  (terminal)  is  active  or  inactive. 

2)  Main  Application  Program-Active  User  Process.  This  is  performed  when  the 
Active  User  created  by  a  User  Handler  process  sends  a  message  (command  -f 
information)  to  CCP  in  order  to  execute  some  specified  operation,  i.e..  The 
CCP  performs  this  command  (calling  BDOS  if  necessary)  and  returns  a 
result  to  the  Active  User. 

3)  Main  Application  Program-BDOS.  This  synchronization  is  performed  when 
the  Active  User  executes  a  command  that  requires  BDOS  participation,  such 
as  a  read/write  segment  to  secondary-  storage.  CCP  receives  the  message  from 
the  user  and  directs  it  to  BDOS.  When  BDOS  executes  the  command,  it 
returns  the  result  to  CCP  which  in  turn  directs  the  result  to  the  Active  User. 

4)  User  Handler  Process-Active  user  Process.  This  is  performed  when  the 
Active  User  is  created  and  communicates  that  it  was  created,  returning  the 
control  to  the  User  Handler.  The  same  communication  is  performed  when  the 
Active  User  finishes  execution  (entering  "bye"). 

When  the  communication  is  between  CCP  and  a  User  Handler  or  an 

Active  User,  the  CCP  must  recognize  which  user  sent  the  message  in  order  to 

return  the  result.    The  synchronization  is  obtained  using  the  following  segments  : 

1)  Stack  Segment.  To  synchronize  the  execution  of  that  process. 

2)  Data  Segment.  To  determine  which  user  was  activated.  The  CCP  stores  the 
previous  value  of  the  data  segment  of  each  process.  When  User  Handlers  or 
Active  Users  send  a  message,  it  advances  the  eventcount  (also  the 
synchronization  segment  eventcount)  then  CCP  compares  this  value  against 
the  value  stored  previously.  If  the  result  is  different  it  means  user  activated, 
otherwise  CCP  checks  the  eventcount  of  the  next  user  until  an  active  user  is 
found. 

3)  Synchronization  Segment.  To  synchronize  the  execution  of  the  CCP.  All  the 
processes  know  this  segment  in  order  to  activate  the  CCP  execution, 
advancing  the  eventcount  of  this  segment.  When  CCP  finishes  execution,  it 
advances  the  eventcount  of  the  process  that  activated  it  previously  and  then 
waits  until  another  process  calls  it  again. 
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The  CCP  knows  the  synchronization  segments  used  by  each  process 
since  they  are  specified  in  the  system  parameters.    The  segments  used  are  : 


STACK 

DATA 

user  handler 

1 

32 

40 

active  user 

1 

45 

46 

user  handler 

2 

34 

41 

active  user 

2 

47 

48 

user  haJidler 

3 

36 

42 

active  user 

3 

49 

50 

The  synchronization  mechanisms  used  here  are  Await,  Advance 
and  Read    eventcount,  as  provided  in  GEMSOS. 

e.  Delete  Processes  Module 

This  module  will  delete  the  processes  created  before.  It  is  executed 
when  users  enter  "bye".  In  addition  to  this,  it  will  also  terminate  and  delete  the 
segments  created  in  the  process  creation  (stack  and  data),  and  will  terminate  the 
code  segment.  The  success  of  this  module  depends  on  the  previous  self  deletion  of 
the  User  Handler  process. 

f.  Terminate  Segments  Module 

This  module  terminates  the  segments  created  previously  (mentor  and 
synchronization  segments).  The  result  is  that  segments  numbered  31  and  51  are 
now  available  in  the  LDT. 
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g.     Delete  Segments  Module 

This    module   returns   the   space   used   by   the   segments   terminated 
before,  and  marks  free  the  entry  numbers  used  to  create  these  segments. 
2.     User  Handler  Application  Program 

The  design  is  like  that  of  the  CCP  design.  The  differences  are  related  to 
the  way  the  modules  perform  internally.  The  function  of  this  application  program 
is  to  create  a  single  access  level  Active  User  according  to  the  user  clearance  level 
determined  during  the  Logon  process.  It  is  also  divided  into  the  following 
modules  : 

a.  Load  Parameter  Module 

This  module  creates  a  table  with  parameters  that  are  needed  in  the 
Active  User  process  creation.  The  parameters  are  the  same  for  all  users'  processes 
since  each  User  Handler  has  its  own  LDT  table.  This  means  that  they  have 
independent  segments.  Again,  Figure  4.5  shows  the  structure  and  numeration  of 
each  segment. 

b.  Create  Segments  Module 

This  module  creates  the  segment  that  will  be  used  as  mentor  of  the 
Stack  and  Data  segments  for  the  Active  L'ser  process.  One  difference  between  this 
module  and  the  Create  segment  module  in  the  Main  Application  program  (CCP) 
is  that  it  does  not  create  a  specific  synchronization  segment.  Another  difference  is 
related  to  the  mentor  used  to  create  the  User  Active  process.  The  L^ser  Handler 
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program's  code  was  used,  because  it  is  unclassified  and  can  satisfy  requirements  of 
security. 

An  unclassified  segment  has  minimum  access  class  constraints  and 
can  be  mentor  of  classified  segments.  As  such  the  segment  that  holds  the  User 
Handler  code  was  used  since  it  is  unclassified  and  satisfies  security  requirements. 
The  inverse  case  occurs  when  a  classified  segment  is  used.  It  can  only  be  mentor 
of  those  segments  with  equal  or  greater  classification.  This  means  that  segments 
with  less  access  class  cannot  be  created,  limiting  the  participation  of  users  with  no 
classification  level.  In  a  multilevel  system,  the  mentor  segments  must  be  capable 
of  handling  different  kinds  of  users  and  segments  associated  with  those  users. 

c.  Create  Process  Module 

This  module  creates  a  single  access  level  Active  User  Process  (only 
one).  The  access  level  is  determined  when  the  user  enters  the  system.  The 
difference  between  this  module  and  the  one  contained  in  the  Main  Application 
program  is  the  resources  assigned  to  the  created  process  : 

Memory      :    60  bytes 

Segments     :    100  segments  available 

Processes     :    0  (cannot  create  child  processes) 

d.  Synchronization  Module 

The  synchronization  used  was  explained  previously;  the  segments 
used  are  : 

1)  Code  Segment.  To  synchronize  the  execution  of  User  Handler  Process. 

2)  Stack  Segment.  To  synchronize  the  execution  of  the  Active  User. 
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This  synchronization  takes  place  when  the  User  Handler  process 
releases  the  attached  terminal,  creates  and  activates  the  Active  User  process 
(advancing  its  stack  eventcount),  and  waits  until  the  Active  User  (child)  finishes 
execution  (entering  "bye"  and  self  deleting).  When  this  happens,  it  terminates 
and  deletes  the  segments  created  to  support  the  execution  of  the  Active  User 
(stack,  data,  mentor  segments),  and  communicates  to  CCP  that  this  user  is 
inactive. 


attach 
terminal 


ACTIVE  USER 
appl .  program 


tamioal 


Figure  4.8    User  Active  Application  Program  Modules 
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3.     Active  User  Application  Program 

This  program  was  designed  following  structured  programming  techniques. 
Figure  4.8  shows  the  modules  that  compose  the  Active  User  application  program. 
These  modules  are  : 

1)  Attach  terminals  (read  -  write) 

2)  Loop  1 

-  Prompt  the  user 

-  Get  user  input 

-  Load  data  segment 

-  Synchronize 

-  Put  result 

3)  Detach  terminals 

4)  Self  delete 

Following  the  same  structure  used  in  the  description  of  the  Main 
Application  program  and  the  User  Handler  Application  program,  the  modules 
indicated  above  are  described  individually  : 

a.  Attach-terminal  Module 

This  module  assigns  a  terminal  to  the  Active  User  process,  the  object 
being  to  allow  the  user  to  perform  I/O  operations.  There  is  a  specific 
Attach    device  call  for  assignment  of  read  and  write. 

b.  Loop  Module 

This  module  handles  the  main  process.  It  starts  with  the  input 
entered  by  the  user,  and  finishes  when  the  user  receives  a  result  for  the  input 
entered.  The  intermediate  steps  necessary  to  get  the  output  result  from  CCP  are  : 

1)  Load  Data  Segment.    The  segment  created  to  pass  data. 
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2)  Synchronize  with  CCP.  Data  segment  is  passed  to  CCP  and  the 
synchronization  segments  are  activated  (advance  synchronization  and  data 
segments  eventcounts;  await  stack  segment  eventcount). 

c.  Detach  terminal  Module 

This  module  detaches  the  device  previously  attached,  returning 
control  of  this  device  to  the  Operating  System,  making  it  available  for  future 
assignnaents  in  other  processes.  There  must  be  a  balance  between  Attach  and 
Detach  calls,  otherwise  a  system  error  will  occur. 

d.  Self  delete  Module 

This  module  holds  the  ending  of  a  child  process.  Self  delete  is 
required  if  the  next  step  is  delete  the  child  (Active  User)  process  from  the  address 
space  of  the  parent  (User  Handler).  When  the  delete  process  is  complete,  the 
parent  recovers  all  the  resources  that  were  assigned  to  the  child  in  the 
Create_process  step.  In  addition  to  the  Self  deletion  call,  a  segment  number  must 
be  specified  in  order  to  perform  the  synchronization.  This  is  due  to  the  fact  that 
when  the  process  finishes,  it  automatically  Advances  the  segment  eventcount 
indicated  in  the  Self  delete  call. 
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V.   IMPLEMENTATION 

A.    GENERAL  DISCUSSION 

Implementation    of    the    model    was    designed    considering    one    application 
program  for  each  process.    The  following  programs  were  developed  : 

1)  Main  Application  Program-  COP  (Appendix  A) 

2)  User  Handler  Application  Program  (Appendix  B)  '■ 

3)  Active  User  Application  Program  (Appendix  C) 

4)  BDOS  Application  Program  (Appendix  D) 

To  this  end.  it  was  necessary  to  construct  the  following  support  programs  : 

1)  Primitive  Calls  ^~" 

2)  Auxiliary'  Functions 

1.     Primitive  Calls 


The  object  of  this  program  is  to  be  used  as  an  interface  between  the 
GEMSOS  primitives  at  the  Kernel  level  of  the  system  and  the  application 
programs.  All  primitives  use  a  record  structure  initialized  by  the  programmer 
before  calling  for  the  specific  operation.  The  set  of  programs  developed  to  perform 
these  functions  are  called  "PROCE";  they  were  built  by  modifying  the 
demonstration  program  provided  by  Gemini  Computers  Inc.  and  adapting  them 
to  the  requirements  of  the  proposed  model. 

The  program  "PROCE"  has  two  extensions:  "PROCE.LIB"  contains  the 
specifications  that  can  be  visible  to  the  user,  and   "PROCE. PKG"  contains  the 
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code  developed  to  handle  these  specifications.  T  .is  is  an  ADA  feature  that  helps 
to  reinforce  security  aspects  (Information  Hiding  Principle). 
The  procedures  developed  in  these  modules  are  : 

PROCEDURE  PRIMITIVE  SUPPORTED 

CR-SEGMENT  CREATE-SEGEMENT 

DL-SEGMENT  DELETE-SEGMENT 

MK-SEGMENT  MAKEKNOWN-SEGMENT 

MAKEKNOVVN-SYNCH  Used  to  makeknown  the  synchronization 

segments  (CCP-to-Active  User) 
TERMINATE-SYNCHR-SEG       Terminates  the  segments  indicated 

above 
FILL-INIT  Fills  the  resources  record  needed  by 

Create-process  primitive 
CR-PROCESS  CREATE-PROCESS 

The  program  listing  is  contained  in  Appendix  E.  Those  GEMSOS 
primitives  not  requiring  record  initialization  (i.e..  Terminate-segment  and  all 
the  primitives  used  for  synchronization)  were  not  included.  The  primitives 
Attach-device  and  Detach-device.  were  separated  into  the  Auxiliary'  Functions 
program  because  they  may  be  called  in  future  applications  that  may  not  need  the 
use  of  the  other  prinaitives  declared  above. 
2.  Auxiliary'  Functions 

This  program  contains  additional  data  structure  needed  by  the  main 
application  program,  i.e..  command  record,  password's  record  description, 
constants  used,  etc..  It  also  contains  procedures  and  functions  to  perform  I/O 
operations  (read  and  write),  and  functions  to  create  parameters  replacing  the 
modules  that  the  system  needs  but  were  not  delivered  in  the  NPS  Gemini  package 
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(The  LDT  entry  allocation  procedure  for  example).  These  were  described  in  the 
design  constraints  of  Chapter  IV.  As  in  the  previous  program,  some  procedures 
and  functions  provided  by  Gemini  Computers  Inc.  were  used  as  a  basis  to 
construct  this  program  segment,  with  the  addition  of  code  and  records  required  to 
support  the  current  research.  This  program,  called  "FILES",  has  two  extensions, 
"FILES. LIB"  contains  the  specifications  and  records,  and  "FILES. PKG"  contains 
the  code  developed.  ■ 

The  procedures  and  functions  included  are  : 


NAME 


TYPE 


DESCRIPTION 


GET-STR 

PUT-STR 

PUT-DEC 

PUT-SUCC 

GET-INPUT 


LOAD-PARAM 


LOAD-ACCESS-CLASS 


LOAD-PARAMl 


Procedure 
Procedure 
Procedure 
Procedure 
Function 


ATTACH-TEW/TER  Procedure 


Procedure 


Procedure 
Procedure 


LOAD-CHILD-ACTIVE       Procedure 


Gets  a  string  from  the  terminal 
Displays  a  string  in  the  terminal 
Displays  a  number  in  the  terminal 
Displays  a  string  and  a  number 
Gets  an  input  string  from  the  terminal 
and  echoes  the  input  if  the  echo  option 
is  on.  It  also  converts  all  the  input  to 
lower  case 

Supports  the  primitive  ATTACH 
DEVICE  specifying  if  the  device  is 
to  read  or  write 

Produces  a  table  of  parameters  with 
information  needed  by  the  main  appli- 
cation program  (segment  number,  entry, 
mentor) 

Produces  a  table  with  the  security 
access  level  depending  on  the  user  level 
Produces  a  table  of  parameters  with 
information  needed  by  the  user  handler 
program  (segment  number  .entry  .mentor) 
Initializes  the  Active  User  record  to 
false.  It  lets  the  CCP  load  the  Active 
User  segments  each  time  a  false  record 
is  found 
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LOOK-FOR-LE\^EL  Procedure       Simulates  the  Logon  process,  loading  the 

access  class  of  the  user  depending  on 
Username  and  Password 

CONVERT  Procedure       Assembles  the  command  line  using 

the  input  message  typed  by  the  user 

The  program  listings  are  contained  in  Appendix  F. 


B.         IMPLEMENTATION  CONSTRAINTS 

Two  factors  dictated  splitting  the  implementation  into  several  steps  thus 
making  the  system  easier  to  develop  and  test.    These  factors  were  : 

1)  Lack  of  System  Documentation  and  prior  experience. 

2)  Time  required  to  develop,  implement,  integrate  and  test. 

At  the  time  this  research  started,  sufficient  information  about  the  system 
did  not  exist.  As  such  numerous  system  "quirks"  posed  additional  time  delays  in 
the  implementation  process.  Upper  level  interfaces  to  GEMSOS  had  to  be 
implemented,  at  times  by  experimentation.  Program  development  using  an 
unfamiliar  set  of  procedures  and  new  functions  is  error  prone,  requiring 
programming  tools  that  are  still  not  available  in  this  machine.  Another 
implementation  constraint  was  the  time  required  for  program  development. 

A   main  factor   related   to   the  speed   of  development   is   the  fact   that   a 

program,  in  addition  to  compiling  and  linking,  requires  a  special  process,  called 

"Sysgen"  prior  to  execution.  Sysgening  takes  longer  than  10  minutes  each  time, 

even  if  only  a  single  line  was  changed.  Since  debugging  tools  were  limited,  it  often 

took  several  attempts  to  find  a  mistake  or  the  exact  way  of  performing  a  specific 

53 


operation.  As  previously  described,  the  "sysgen"  process  has  the  functions  of 
creating  and  formating  logical  volumes  in  secondary'  storage,  and  creating  a 
bootable  Gemini  System  Segment  Structure  on  formatted  volumes.  This 
second  function  is  called  each  time  a  program  must  be  loaded  to  execution  [Ref. 
8:p.  l].    The  use  of  the  system  program  (sysgen)  is  explained  in  [Ref.  8:pp.  8-18]. 

C.         IMPLEMENTATION  STEPS 

The  basic  approach  starts  with  a  model  using  the  demonstration  program 
provided  by  Gemini  Computers  Inc.    The  primary  steps  followed  were  : 

1.  Single  User.  Single  Security  Access  Level 

This  step  established  the  ability  to  create  a  child  process  and  to 
establish  com.munication  between  parent  and  child  processes.  The  main  issue  here 
was  the  stack  size.  Its  size  had  to  be  determined  experimentally  (AFFF  hex),  since 
it  is  not  clear  as  to  the  correct  way  to  measure  the  size.  The  size  of  the  stack  is 
determined  by  the  following  constants  : 

stack-size  =  vector-size  +  segment-manager-size  -i-  constant 

=        4  bytes  76  bytes  AFFF  bytes 

The  size  of  the  last  constant  was  derived  empirically,  and  is 
apparently  a  combination  or  the  amount  of  memory  needed  to  create  a  child 
process  and  the  number  of  processes  that  can  be  activated  simultaneously  in  the 
system. 
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2.  Several  Users.  Single  Security  Access  Level 

This  step  proved  the  creation  and  synchronization  among  several 
processes.  The  key  points  were  : 

a)  The  hierarchical  structure  of  the  system  required  special  procedures  for 
handling.  A  procedure  was  created  to  dynamically  determine  the  next 
segment  available  in  the  system.  This  procedure  was  written  to  associate  the 
next  segment  number  to  be  used  in  process  creation,  and  the  entries  used  by 
each  segment.  The  resulting  table  of  parameters  created  by  this  procedure 
was  previously  shown  in  Figure  4.7. 

b)  A  synchronization  method  among  processes  was  needed,  which  included  the 
structure  needed  to  determine  which  process  was  activated  (two 
synchronization  segments  for  each  process). 

c)  Communication  between  processes  was  developed  (passing  information).  The 
procedure  Move_bytes  is  considered  to  pass  information  from  one  process 
to  another,  an  example  and  further  explanation  is  provided  in  [Ref.  9:pp.  5- 
6]. 

3.  Several  Users,  Multilevel  Security  Access 

This  step  introduced  the  security  constraints  needed  to  work  in  a 
multilevel  secure  system,  the  key  points  were  : 

a)  Creation  of  a  Child  process  (Active  User)  by  another  child  process  (User 
Handler)  previously  created  by  a  main  application  program  (CCP).  This 
addresses  the  resources  passed  by  the  parent  process.  A  balance  was 
achieved  between  the  resources  passed  by  CCP  when  it  creates  a  User 
Handler  process,  and  the  resources  passed  by  the  User  Handler  process  to 
an  Active  User  process  during  its  creation.  In  other  words  the  following 
constraints  were  applied  : 

(User  Handler  (1  +  2  +  3)  +  BDOS  resources)  <  CCP  resources 

Active  User  resources  <  User  Handler  resources 

b)  Development  of  three  kinds  of  synchronization  :  between  Child  (Active  User) 
and  Parent  (User  Handler);  Grandchild  (Active  User)  and  Grandparent 
(CCP);  Parent  (User  Handler)   and  Grandparent  (CCP).  Different  segments 

55 


pa-thname 


31 
32 
33 
34 
35 
36 
37 
38 

39 
40 
41 
42 
43 
44 
45 
46 

47 
48 
49 
50 

51 

0-19  kernel 

5,5 

5,5,1 

5,7 

5,5,2 

5,8 

5,5,3 

5,9 

5,5,4 

5,10 

5,5,5 

5,5,5 

5,5,7 

5,5,8 

5,7,3/5,8,3/5,9,3 

5,7,3,1 

5,7,3,2 

5,8,3,1 

5,8,3,2 

5,9,3,1 
5,9,3,2 

5,5,11 

20  -  24  address 

specif . 

25  -  30 

Qot  used  here 

users '  mentor 

stack  user  1 

code  user  1 

stack  user  2 

code  user  2 

stack  user  3 

code  user  3 

stack  BDQS 

code  BDQS 

data  user  1 

data  user  2 

data  user  3 

data  BDOS 

mentor  chid  users 

stack  chid  user  1 

data  chid  user  1 

stack  chid  user  2 

data  chid  user  2 

stack  chid  user  3 

data  chid  user  3 

SYNCHRONIZATION 

Figure  5.1    Main  Application  Program  LDT 


were  used  to  synchronize  the  execution  of  Active  User  and  User  Handler  from 
those  used  to  synchronize  Active  User  with  Main  Application  (CCP)  or  User 
Handler  with  CCP.  The  synchronization  of  the  Main  Application  program 
with  all  users  was  implemented  through  the  same  segment. 

c)  Restrictions  imposed  on  segment  handling  due  to  security  access  levels; 
segments  with  equal  or  greater  access  class  must  be  passed  between  processes. 
The  security  access  level  is  composed  of  two  parts  :  Compromise  (Observe) 
and  Integrity  (Modify).  This  research  worked  within  Compromise 
constraints.         Integrity       involves       levels       in       the       system's       rings, 
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compartmentalization  (audit,  operator,  programmer,  etc.),  and  the  concept  of 
ring  brackets.  In  order  to  keep  the  model  simple,  integrity  was  not 
considered.  The  execution  of  each  primitive  checks  security  constraints  and  if 
satisfied,  the  execution  continues,  otherwise  the  system  aborts  for  security 
reasons. 

d)  Main  Application  Program  Segment  Distribution.  Figure  5.1  shows  the  LDT 
table  including  all  segments  needed  by  the  seven  processes  (3  User  handler 
processes.  3  Active  User  processes,  and  BDOS  process).  It  also  presents  the 
segments  used  as  mentors  of  other  segments  (31  and  44)  and  the  segment 
used  to  synchronize  the  CCP  (51). 


D.         SYSGEN  SUBMIT  FILE 

Appendix  F  shows  the  Sysgen  Submit  File  used  to  define  the  structure  of 
the  application  programs  developed  in  this  research. 
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VI.    CONCLUSIONS  AND  RECOMMENDATIONS 

A.         CONCLUSIONS 

1.  System  Operation 

The  security  check  starts  with  the  logon  process.  If  the  operator 
has  a  valid  usemame  and  password  that  is  recognized  by  the  system,  then  the 
security  level  of  this  operator  is  adopted  for  the  terminal,  otherwise  the  system 
continues  prompting  for  the  usemame  three  more  times.  Failing  a  correct 
response,  the  system  restarts  the  logon  process.  The  main  testing  performed  was 
the  validation  of  the  segments  defined  in  the  submit  file.  If  they  were  "classified" 
the  operator  had  to  satisfy  the  security  constraints  in  order  to  use  this 
application.  Otherwise,  the  system  aborted  the  execution  and  prompted  for  a  new 
logon  operation. 

The  application  programs  work  according  to  the  design,  dynamically 
loading  the  user's  security  level  in  the  "terminal  logon"  process.  Access  is  limited 
to  those  users  recognized  by  the  system  and  restricted  to  the  use  of  information 
based  on  the  user's  access  level.  The  interaction  between  Active  User-CCP-BDOS 
is  performed  within  security  constraints  (only  compromise).  The  messages  passed 
are  "processed"  by  the  CCP  and  results  are  returned  to  the  user. 
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2.  System  Performance 

Because  of  the  NPS  system  configuration,  the  performance  of  the 
application  program  is  degradated  for  the  following  reasons  : 

-  Single  processor  emulating  parallel  processing 

-  Secondary  storage  consisting  of  only  floppy  disks 

-  Programmed  I/O  environment  instead  of  interrupts 

B.         RECOMMENDATIONS 

1.  Hardware  Improvements 

A  system  upgrade  should  be  considered  which  at  least  addresses 
adding  a  hard  disk  to  the  present  configuration.  This  would  provide  an 
improvement  in  the  access  time  required  to  handle  segments  and  decrease  the 
response  time  in  process  creation.  In  addition,  there  would  be  a  considerable 
reduction  in  the  system  development  time,  i.e.,  the  time  required  to  compile,  link 
and  sysgen.  frequent  operations  in  the  development  phase. 

Additionally,  to  take  full  advantage  of  the  machine's  parallel 
processing  abilities,  more  processors,  two  at  least,  should  be  added.  Memory 
expansion  would  relax  many  restrictions  currently  imposed  on  process  creation  as 
utilized  in  this  thesis  work. 

2.  Software  Improvements 

The  current  system  as  delivered  was  incomplete  with  respect  to  the 
modules  necessary  to  develop  application  programs  in  the  Janus/Ada  language. 
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Software    improvements    should    include    better    documentation    related    to    the 
system  and  debugging  and  programming  tools  for  the  application  programmer. 
3.  Future  Research 

As  a  result  of  the  research  presented  in  this  thesis,  areas  of  related 
research  should  include  the  following  : 

a.  Directly  Related  to  this  Research 

(1)  Inclusion  of  integrity  access  constraints  (modify)  into  this  current 
implementation.  In  this  thesis,  system  integrity  was  considered  at  its 
minimum  level  in  order  to  execute  the  application  programs  without 
limitations.  Since  this  is  a  main  issue  with  respect  to  the  information 
security,  a  careful  implementation  should  be  developed  working  in  this  area. 

(2)  Development  of  interrupt  driven  environment  in  the  current  design. 
The  initial  design  using  the  BIOS  module  is  an  event  driven  svstem.  This 
design  approach  was  not  used  due  to  present  hardware  limitations  as 
explained  in  Chapter  I\'.  "Initial  Design  Constraints". 

(3)  Addressing  (solving)  the  issue  of  a  restricted  LDT  size.  This 
restriction  is  due  to  a  limited  number  of  application  programs  or  application 
program  complexity,  since  an  upper  bound  of  27  segments  are  available  for 
the  user  from  the  bounded  LDT  of  52  that  a  process  can  have. 

(4)  Implementation  of  the  "terminal  logon"  method.  This  function  is 
simulated  in  the  actual  development  through  a  module  that  loads  the  access 
class  of  a  recognized  user.  A  possible  solution  would  be  the  conversion  of 
those  libraries  provided  by  Gemini  Computers  Inc.  from  Pascal  language  into 
Ada  language. 

b.  Related  to  Secure  Mass  Storage  System 

(1)  Development     of    softv/are     "crossbar"     in     the     Concentrator    for 

integration   of  the    Gemini   computer   into   the    Naval   Postgraduate   School 
Laboratory'  as  a  Secure  Mass  Storage  System  (S3). 

(2)  Implementation  of  BDOS  using  a  design  for  a  one-level  segmented 
secondary'  storage  system  and  a  large  capacity  hard  disk  (mass  storage). 
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APPENDIX  A  -  MAIN  APPLICATION  PROGRAM  (CCP) 

This  appendix  presents  the  Main  Apphcation  Program  code, 
including  the  modules  developed  to  handle  the  dynamic  sharing  of  system 
resources.  Instead  of  the  present  system  consisting  of  several  program.s.  each 
containing  one  module,  all  modules  are  grouped  into  one  main  program  with  the 
indicated  modules  separated  by  comments.  This  program  is  called  "PRMAIN" 
and  is  listed  below. 
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pragma  rar2echeck(  cff  );  pragma  detug(  off  ); 
prsi^ma  ari  thcherk(  off  );  pragrra  enutatC  off  ); 

WITH  agate,  agatej,  arl,  alit,  alibj,  strlit,  util,  proce, 

files; 
PACKAGE  EOElf  prrrain  IS 
USE  agate,  agatej,  arl,  ali"b,  alibj,  strlit,  util,  proce, 

files; 

*'*  •*»    »•»   «**  *•*    »•*    «i>   «J*    »'*   »•*   *'*    »*•    ***   «.'*    *'*   «J*   0«  ^>^    «>«  ^«     >ttf  *>*    i%lrf   «■«    «•«   0«    it*    *'*  »'*    *'*    ok*  WU    •**  v'*    »•*    *•*    >.>*  *'•    ■»•*    <Jkv  *'*   ,^     ,'»    sl«    »'if  •'*    -J*    »'•   *'*  *•*    *l.    »■*  v'^    0>      .1*   ^'^ 

•M  •^  •!*  t*  1*  'r*  *t*  'I*  *i*  'I*  'I*  'I*  'i"  *!■»  *i*  T*  'I*  'I*  "t*  '»*  I"*  n"   *»■■  'l*  '^■"  '«*  f*  '^^  'i*  T  'r  'I'*  'I*  'i*  '»*  1*  *P  *>■•  '1*  '►'  '(*  ',••  ',■*  1*  'i*  'i"  *»*  '(•  I*  •,»  *p  "-I*  '«»■  '(•  ^t*  7|*  -"i*  *!■• 


Corsstants   used   ty    the    prograrr    : 


STDIO  >:    — > 

STDIO  R    --> 

10  FORT    — > 

PREEOS     — > 

STEIC  'A'  :  CONSTANT 

STEIO  R  :  CONSTANT 

10  PORT  :  CONSTANT 

NUMBIR  OP  USERS  : 

NUMBER  OF  PROCESS 

PRBDOS  :  CONSTANT 

NU^BER  FROCFSSES  : 

MEMORY  AVAILABLE  : 

SEGMENTS  AVAILABLE 

assigns  logical  device  1  to  write 

assigns  logical  device  0  to  read 

main  program  uses  port  0  of  the  RS-232 

process  number  for  the  BDOS 


integer  :=  i; 

integer  :=  0; 

integer  :=  0;   —  pert  zero  for  main 
CONSTANT  integer  ;=  3; 
:  CONSTANT  integer  :=  4; 
integer  :=  4; 

CONSTANT  integer  :=  i:   —  #  cf  childs 

CONSTANT  integer  :=  130; 

:  CONSTANT  integer  :=  300; 


—  Variables  used  by  main  program 


w_class 

success 

mode 

mode_r 

def_off 

def  seg 

rl_def_si 

synchr_se 

ch_out  : 

ch_in  :  i 

ch_res  our 

init  :  rl 

rd_str  : 

class 

men t  or 

entryx 

seg_mode 

seg  numbe 

CCP'EUSY 


access_cl ass ; 

integer; 
at tach_ struct ; 
attach_struct ; 
integer; 
ir  t eger ; 
ze  :  integer; 
g  :  integer; 
comard_lire; 
nput^message ; 
ce  :  child_re50i:r  ce  ; 
_prccess_def ; 
string; 

access_cla5s; 
integer; 
integer; 

seg_access_type ; 
ir teger; 
boolean ; 


security  aspects 
result 
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ch_parar:e ter  :  rl_par£me  ters  5 
ch_pardr)  :  rl_para!T; 
ch_level  :  U5er_levei; 
ch  acces5_level  :  level_reccrd ; 
ch"ch_user_s,ynchrc  :  users  _act  ive  ; 
ch_ch_evc_val      :  integer? 
proces    :  integer? 
no_act  ive_ii5er5  :  integer* 
evc_value  :  inte^-erJ 
evc_active  :  integer? 
active_u5er  :  integer? 
index     :  integer? 


—  r^AIN 
BEGIN 

init 


=  get  rl  def 0 


this  sentence 
olDligatory 


1  s 


fci^  »•>  «)*  *'*  •■'<  »'*  *''  »'*  •'#  >'*  V*  *'^  s'*  *'*  *'•  *'•  •'*  V*  *'*  *'*  *■'' 

r,<k  *,«  *,«  «|«  ')«  ^,«  '|V  »|«  ')«  ^i«  #)«  'i^  7f«  '|«  'i*  »i^   '!«  ^|«  '(«  'i^  'p 


»'*  »'rf  »'*  fc'*  »'*  *'*  «'i*  «'*  *'«•  *'*  *'»  ^l*"  •.'*  •%>*  -,lr    *'rf  »'*  ^1^  *'*  «■*  <«'»  fc'rf  *t,  ^1,  ^ 
'l*  'I»  *^»  ^(*  ^,"  ^|»  *^^  'i*  »•,*  *|»  *,*  *|"  ^p.  #,*  *,»  »,»  *,*  y,«  ^,^  w,«  «|«  ^,>>  ,f,x  V  »  r 


attach  serial 
This  sentence 


port  for  writing, 
is  optional  and  is 


;sed  to  display  messa- 


ges provided  ty  the  main  application  program  on  the 
screen  . 

attach_tew(  I0_PORT,  STDIO_V.'  )? 

lit_set_tracket (  1,  1,  1,  init .resources  .nin_clas5  )? 

«i«  »'*  »•*  *••  »'*  %•*  »'»  »'*  V'  >''  »'*  *'•  •.'*  O*  «•*  *'»  *'*  *'*  *'*  fc'*  *'*  ».•*  *'*  *'»  *•*  *'*  »'*  fc'*  *irf  «)«  v'«  ^1*  *'»  *'*  *Jr  •.'#  *'*  *'^  •,'*  ^<«  *'*  *'*  «'.»  %'*  «,)«  %'»  %•*  *'*  *'*  »,t^  *•*  x'»  •'.>  ^i^  «'y  h'« 
^1'*  »|*  *(^  *,■•  *,»  *jN  *,•  *|»  >j*  *|»  ^j»  *(■•  >|%  >i»  *>,»  *,«  *j»  *(»  *|%  *|^  tf|«#|«  *|«  *,»  *,»  *(»  *,*  ^»  ^j%  *,»  *,*  *|*  *|*  *|»  *■,*  #1*  *,»  *j-»  *,*  ^|«  *)»  *(*  *|^  *,*  *|»  *|*  *|*  *, »  *,* «,«  *■!*  *|«  ^1*  >|^  »j%  ^,» 

LOAr    PARAKiITIRS    r^ODULE 


_—   Ti 


This  module  assigns  fixed  parameters  to  each  process 
that  will  te  created.  The  parameters  are  mentor  number 
entry  numher,  segment  numter.  They  are  used  to  create 
each  segment  needed  ty  the  process  to  te  created 
(USER  EANTLER).  There  is  a  group  of  these  parameters  for 
the  stack,  code,  and  data  segmei^ts 


load_param ( ini t ,  ch_param)? 

load  child  actives  array  are  additional  parameters 
used  ty  the  main  application  rrogram  tc  synchronize  its 
operation  with  the  ACTIVE  USER  processes 

load_child_active(ch_ch_user_ synchro)? 

load  access  class  that  each  process  will  have.  In  cur 
case  all  the  processes  will  te  multilevel.  Minimum  is 
unclassified  and  maximum  is  top-secret 
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load_access_class(init,ch_level); 
w_class    :=    ini  t .  resource  s .  rrax_class; 

«•«  «'*  »'■  *'*  \.>r   *•*  *'»  »'*  •'*   •.'*  »'*  *'*  *•'  »'*  »'■•  »'•  »'•  *'*  *'^  *''    *'<•  ^''  ^''  V'  ^'*  *'*  ^''  ^''  *'*  *'*   *'•  *'^   >''  *''   *'•  *'^  • 
^1*  ^1%  'i^  ^|4  ^^   ^.^  'i^  ^.x  ^.^    ^1^  ^1^  'i^  ^1*  'i^  '.^  J.*  'i^  ^1^  ^     '1^    'l^     i^      1^      1^  'l^  't^      1*  ^>^  'I      *l*  'i^  'I*      1^  'l^   'l^  ^1^  ' 


»  ».'j>  *'*   »'»  ***   >'*  •><«  «,'«   «■«  »•*  «,'*   «■<  ^'« 
*  *,%  ^,»   *■!*  "i*   *|*  *,*  *|»  *(»  *,»  *,•   *|*  *^ 


>;:5 


>•  5|C  ^C  5,*  ^■i^  rf>  *,■*  *|S  ^,*  *|".  r^-*  *)»  ^i*  *(*  *,••  *,•  ^-t  ^i*  *(■*  5)»  'i>  ^(^  *iC  ^%  ^1*  *■,*•  *p  *)C  ^,s  *,*  ^,N  *,»  ^,»  *,C  *,v  *,C  Jji  2,'  5,C  *i«  ?|C  5,»  5,4  ^,s 


—  CKEATS  SEGMENTS  MODULE 

This    module    creates    the    segrrents   needed   for    the 

followin,^    : 

a.-   Mentor  of  the  stack  and  data  se^rrents  of  each 
process  and  ?COS  process.  The  standard  elected 
was  use  entry  5  of  the  nientor  intial_5e^iner.t  ( 2 ' 
"application  mentor"  and  call  this  new  se/^ment 
31  in  the  LDT  of  the  main 

b.-   Synchronization  segment.  Its  mentor  is  the 

—  segment  created  in  the  previous  step,  entry  11 
of  segment  31  was  elected  and  this  rew  segment 
was  called  51  in  the  sarr^e  LTT.  The  access  class 
is  TCP-SECRET 

ch_access_level  :=  ch_level(l); 

mentor     :=  ini t  .ini t ial_seg (2  ); 

entryx     :=  5J 

class      :=  ini t . res ources .min_class » 

cr_segment^in it, mertor,entryx, class, success); 

ifsuccess/^Cthen 

put_succ ( "success  value  20  is" , success  ,w_cla ss ) J 

put_ln(STCIO_W,w_cless, "") ; 
END   If; 

nakekwcwn  this  segment  with  numter  31 
seg_mode   :=  r_w; 
seg_numter  :=  3i; 
mk_segment(init,mentor,entryx,seg_numter, 

seg_mode , success ) ; 
if  success  /=  ?  then 

put  succ ( "success  value  21  is  ",  success ,w_cla ss ) ; 

put~ln(STDIO  W,w_class,""")  ; 

END  if; 

create  synchronization  segment    (max  access  class) 

class  :=  ch_access_leve 1 .max ; 
mentor  :=  3i;      —  segment  31 
entryx  :=  11; 
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cr_se^rrent(init,rrentcr,entryx,clas5,succe55)5 
if  success  /=  0  then 

put_succ( "success  value  7Z    is  ", success ,w_cla ss j 5 

put_ln(3TriO_W,w_class  ,""  ); 

EME  if; 

—     makekncwn    this    segment    with    nurrter    51 

seg_mode    :=   n_a; 

seg_nurrher    :=   ?i; 

mk_sei2;n"entfinit,mentor,entr,yx,5eg_nurr:'ber, 

seg_rncde  ,  success  'i  \ 
if  success  /=?  then 

put_sucr ( "success  value  24  is  ",  success  ,v_c la ss  ) ; 

put_ln(STEIO_'*'  ,w_class,""  ) ; 

IND  if; 

synchr   seg    :=   seg   nurrter; 


—  swapir  this  segrents 

swapin_segment(synrhr_seg, success); 

if  success  /=  ?  ther 

put_sucr( "success  value  05  is  ", success, w 

put_in (STrio_v; ,w_cicss ,"'  ) ; 
END  if; 

*'*  i'i  2*;  *''  *'*  *'*  *'*  *''  *V  *'"  *'*  *'•  *'*  *'*  *'*  •■'■'  *'*  ***  *'*  *'*  *'*»t*  »'*  »'*  *'*  *'*  *'•  •.'-  *'*  »'^  »'*  »•*  Oii^i^  *'*  »•*  •>)««>>  .l'^  ».i>  ko  *.<i*  k'^  *,!«  • 
•— -*  "i*'!*  'i'  'I* 'I*  *i*  'I*  'I*  »i^  'I*  ',*  *t*  'I*  '!■*  'i*',"  *|» 'i*  *|* *|*  ^«3|«  *!*  »p3,**-,»  *,»  *,-.  *,•  >jC  >,C?,-  i,i;,C  5,»  ?,*  ?,J5vC  i,I  >,S  ii*5,C  5,*  5,'  3 


cla  5S 


»  ^  I-  »!•  'f  'f  »i»  -i»  ».-  »i»  »i-  -I-  »i-  Ji-  3|- »,~ .,» '!>  »i« »,»  »,- »,»  -,-.  J|. ',»  »,» »,.  »,-  >,.  5,.  »,• .,.  ;,.  J,.  -|.  ;,c ;,;  ;,:  j,;  ;,;  ;,:  ;,< ;,{ ;,;  ;,;  ;,c  ;|i  ;,c  ;^;  ;^? ;;;  ;^;  ;|c  ;|i ;,; ;;;  ; 

—  CREATE  PROCESS  mQEULE 

—  This  !Tcdule  creates  4  processes 

(3  user  handler  and  1  EDOS) 

put_ln(STEIO_W,  w_cla5s,  "PEGIM  PROCESS  CREATIOM"); 

—  START  CREATING  FACE  PROCESS  IN  THE  SYSTEM 


process  1  ====>  TERMINAL  HANTLER 

process  2  ====>  TFRMIMAL  HAMELFR 

urccess  3  ====>  TERMINAL  HANDLER 

process  4  ====>  rdcs  HANELER 

index    : =    1 ; 

while    index    <=    NUr'RFR_0F_FR0CE3S      LOOP 

ch_  Da  name  ten    :=    ch_pararr  (  index  )  ; 

all    the   pro'^esses    will    have   rrultilevel    access    class 
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rh_access_level  :=  ch_level{l); 

lead  the  resources  that  the  child  will  have 

meiTory  — >   102    (converted  to  E24  forpat) 

segments  >  302 

processes    1  (rrax  nuTler  of  i-roc.  that  can  create!* 

ch_rescurre.nerrory  :=  MIMORY  (i.VAILAPLF; 
ch_re50urce  .segments  :=  SEGr^ENTS_AVAILAELE; 
ch_resource. processes  :=  MUriEER_PROCESSES  ; 

read_evcfsynchr_seg,  evc_vali:e,  success  )5 

cr_process(init,ch_parameter,ch_acces5_level, 

index, ch  resource, synchr_se^,  success)* 


—  synchronize  each  tine  to  let  the  new  process 

—  its  niessa^e  (word  USER) 

awai t ( synchr_5es ,  evc_value+l,  success)' 
index  :=  index  +  i; 

end    loop; 

J,  fct*    »lw    *,'*  «•*     ,t*    v'»    *t*   ••'*    ***   O*    »'•    »•'*  ***    >i**    *'*   »'*   ^t,   %•*  V'      •'*  *''    *''  **'   *''  *'•'   *''   *''  *■''    *''    *'*  *'*   *''  **'    *'*   *'*    *'*  *'i 
^^  ^M  5|'»  ^|»  '(»  *)*  'i*   *|*  *|»   *^»  *i»  'p  ',"•  'i^  *!■•  *,*  '■,■•  'I*  *|*  'i*  *(i  'i*     '(•  'i*    'i*  '|»  'i*  'I*  "i"*  '.^  'l'*    'i*  'I*  'i*  'I*  '!■*  'i""  '(*   'l*  't* 


spiays 


*«  «'«  »'#  «'»  «!'  «*«  O'  «''  •''■  «*'  «'■•  v''   »''  ^'*  0«  «*«  «'«  «*^  «'<  «''   ^''  ^'^  «*'  *•''  *•''  «*'  ■^'^  ^''  ^''  «''  %*'  *'•*  «''  V'  *''  ^''  0««l«  •>*  «t«  *>«  «'«  «■«  kO  «l^  «'«  K>>  «*^  «■««>«  «>«  •■■^«i>   &■«   iti«  K 
>l«  ^l«  *f*  «l«  ».«  #|»  ^1*  ',«  'i^  'p  ^,«  ^|«  'i^  #|«  ^|«  «|«  '|«  «|^  ')^  #1%  «f^  «|^  '(^  '1^  'i^  ',>  'i^  ',^  ^1^  ^|>  ^^*  r|«  #f«  #)»  ^^  d^■^  ^|«  #|«  #1*  ^|«  «|«  ^jv  «•,«  ^|«  >,«  *^«  ^,'«  ^,^  «•,%  ^|«  «|«  «|«  «,>  ^|ik    r  ■*  r 

SYNCHRONIZATION  PROCESS  ANI  LOOP  UNTIL  NO  USER  IS 
ACTIVE 

This  rrcdule  executes  the  synchronization  anonr' 
processes,  starting  with  the  synchronization  with  the 
user's  hardier  processes  and  then  with  tne  active  user 
processes  when  these  have  leen  activated 

ACTIVATE  USER'S  PROCESS 
This  step  stores  the  value  of  the  eventccunts  ir  the 
users'  segments,  the  otject  is  to  Irncw  which  user 
sent  the  messaf;e 

index  ; =  1 ; 

while  index  <=  NUMBIR_OF_USERS   LOO? 

read_evc(ch_pararr(  index)  .  ses_nurr'ber_stack:, 

ch_pararr:  (  index;  .evn_CGunt ,    success    ); 

read_evc(ch_paran-(  index  )  .seg_numher_data  , 

ch_param( index) .evn_ccunt_data , success  )? 

advance  (ch_param(  index  )  .sefr_nuriber_stack,success    )  J 

index    :=    index    +    i; 
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e'-d  loop; 


LOOP  UNTIL  NO  USER  IS  ACTIVE 
This  loop  is  thp  nain  process's  riodule  in  the  whole 
systerr  tecause  will  "be  in  execution  until  all  the  users 
finish  their  jobs  (enter  the  word  "tye"} 

CCP_BUSY  :=  false; 

no_active_u5ers  :=  ?; 

while  no_2C tive_use rs  <  NUM5ER_0F_USERS   LOOP 

if  CCP_EUSY  then 

CCP_BUSY  :=  false; 

else 

read_evc ( synchr_ se^  ,  evc_value,  success  )» 
await(synchr  se^,  eve  value+1,  success  ); 

ENI  if; 

ac ti ve_user  :  =  0 ; 
index  :=  i; 

deterrrine  the  user  that  sent  the  rressage  comparing  the 
event  count  value,  different  value  means  that  user  was 

while  index  <=  iMUMBER_OF_USERS    LOOP 

read  _  eve  (ch_param(  index).seg  nurrter_data, 

evc_active,  success  7; 
if  (evc_active  > 

ch_-Dararr  (index  )  .evn_c  oun  t_data  )  then 
active_user  :=  Index; 
ch_param( index ) .evn_ccunt_data  := 

evc_acti ve; 
index  :=  NUr'EE?._OF_USERS  +  i; 
else 

index  :=  index  +  i; 

END  if; 
ENE  loop; 

checks  if  the  activated  process  cane  from  an  user 
handler  or  an  active  user.  If  carne  from  the  active 
user  it  means  that  the  variahle  "active_user"  is  in  '2, 
otherwise  it  means  that  the  communication  is  between 
a  user  handler  process  and  the  main  prOi^cram  (CCP) 

if  active_user  /=  0  then 

def_5eg    :=  1  it_mk:_5el  ( Id  t_  table  , 

ch_pararr(active_user).se^_number_tiata); 
def_off    :=  0; 
rl_def_size  :=  input_mes5age 'SI ZE/8 ; 
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move   ty tes(def _se^,def    off, .set    ss(), 

ch_in'ADCRISS,    rl_def _s ize) ; 
ch_parameter    :=   ch_rararr  (act ive_user) ; 
if    ch_ch_^use  r_5ynchro  (ac  ti  ve_user)  .act  ive    then 
ch   ch   user    synchro (act ive   user). active    := 

false; 

terrninate_synchr_5ec;(init  ,ch_pardn'ieter  , 

ch_in. in  put_clas5, success'!; 
if    success    /  =  ,,^    then 

put_succ("terrr:nate    ", success, w_cla5s); 

put_ln(STDIC_W,w  class,""); 

end  if; 

if  ch_in  .input _ one  =  "tye"  then 

no_act  ive_users  :=  no_acti  ve_i:sers  +  i; 
else 

advance ( 
ch_param(active_user).seg_num"ber_  stack, 
success ) ; 

INL  u; 

else 

if    ch_in  .input _ one    /=    "lye"    then 

mak'e_lcn ow_sy  re  (  ir, it  , ch_pararieter  , 
ch_in  .  input _cldS5 ,    antive_user, 
ch_ch_ii  ser_  s.ynchro,    success  )  ; 
ch_ch_u5er_si'r]chro(  acti  ve_u5er  j  .active    :  = 

TRIJI:; 
advance ( 

ch_pararr(active_u5er)  .se^_nurrter_stacK  , 
success ) ; 
el  se 

no_active_u5ers    ;=   no_active_users    -^   i; 
?ND    I?; 
ENE  if; 

ELSE 

index    :=   i; 

while  index  <=  NUr^ElP._OE_USIRS   LOOP 

if  ch_ch_user_synchr 0 ( index ). active  then 

read_evc(ch_ch_user_synchro(index;.seg_data, 

ch_ch_evc_val  ,  success); 
if  ch_ch_evc_va 1  > 

ch_ch_user_sy nchro ( index) .evc_data  then 
active_user  :=  index; 
ch_rh_user_sy nchro (index) .evc_data  := 

ch_ch_evc_val ; 
index  :=  NUMEER  OF_USERS  -  i; 
END  IE; 

FNL  if; 

index  :=  index  +  i; 

END  loop; 

if  active  user  =  0  then 


es 


put_ln ( STDIO_V  ,w_class , "active  user  error")* 

def_seg    ;=  lib_rk_sel( Idt _tatle  , 

ch  _ch_user_5yr.ch  re  (dctive_user).5eg_  data); 

def_cff         :=   e; 

rl_def_si2e    :=    input_rrie5sage  '  3  IZE/8  ; 

r^ove_tytes(def_seg,def    cff  ,get_5s()  , 

ch_i  n  'ADEP.I'SS  ,    rl_def_size); 

convert(ch_in,w_clas5,ch_cut); 

—  pass    the    segrrent    to   prbdos    process 

def_seg    :=   li t_mk_sel (ldt_tatle  , 

ch_pararr(PREr)OS  )  .5eg_number_data)  ; 
def_off        :=  0; 

rl_def_size    :=   c  crrar.d_l  ire' SI  ZE/8  ; 
rr^ove    tytes(get_s5()  ,  ch_Gut 'ADDRIS5  ,def_5ep: , 
def_off ,rl_def_size    ); 

—  ACTIVATT    :?r03    PROCESS 


advaricei  ch_-Daran(  FREDOS  )  .  5eg_nurnler_5  tack  , 

success    ); 
read_evc( synchr_seg,    evc_value,    success); 
await(syrchr    seg,    evc_value*l,    success    ;? 


RjCeivid  n'issage  with  result  has  to  be  passed  to  the 

USER 

def_seg         :=    1  it _mk_ sel ( Id t    table, 

ch_parar(FRBr'OSl  .seg_numter_data  ); 
def_off         :=    ?; 

rl_def_size    :=    ccridnd_l  ine 'S  IZE/S; 
move_l:ytes(dpf_seg,def_cff,get    ss(  )  , 

ch_out  'address,    rl_def_size); 

assernble   user   message    with    the    result 

ch_in . irput_result    :=   ch_out  .resul t ; 

—      pass    the    segrrent    to   user    process 

def_seg    :=  lit_mk_sel ( Idt _table , 

ch_ch_user_synchro (active    U5er).seg   data); 
def_cff         :=   0; 
rl_def_size    :=    i  npu  t_rr.essage  '  3  IZE/8  ; 
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rove    t:/tes(get    ss(  )  ,ch_in 'ACEHISS  .def  _seg  , 
def~cff,rl    def    size    ); 


advance  the  process  that  executes  the  command 

ddvarce(ch_ch_user_s,Yrchro(active_-a5er).5ei^_stack, 

success  )  * 

EMD  ir; 


active  user  :=  2  ', 


index 


=  i; 


deterrine  if  while  CCF  was  tusy  executing  the  previous 
commands,  some  user  handlercr  active  user  sent 
a  messaf^e 

USIR  EANI^IIR 

determine    the   user    that    sent    tne    rressa^e    coTparing    the 

eve^rt  court  value,  different  value  means  that  user  was 

while    index    <=   NUr^BrR_CI_USERS        LOOP 

read  _evc'(ch_param(  index)  .see  rumter_data, 

evc_active,  success  T? 
if  •evc_active  "> 

ch_param (index ) .evn_count_d  ata /  then 
CC?_EUSY  :=  TRU?; 
active  user  ;=  index; 
index  7=  NUr.£EE_OF_USEES  +  i; 
else 

index  :=  index  +  i; 

END  if; 
END  loop; 

ACT  rVE  USER 
cetermire  the  user  that  sent  the  message  comparing  the 
event  count  value,  different  value  means  that  user  was 

index  :=  i; 

if  activp_user  =  2  then 

while    index    <=    NU^■PER_OE_USERS      LOOP 

if  ch_ch_user_synchro( index  )  .active  then 

read_evc(ch_ch_user_synchro (index)  .seg_data  , 

ch_ch_evc_val,  success)* 
if  ch_ch_ev  c_val  '^^ 

ch_ch_user_synchro( index ) .eve  data  then 
CC?_BUSY  :=  true; 
index  :=  NUMEER_OE_USERS  +  i; 
END  IE; 
FND  IE; 
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index    : 
END  lcof; 

ENC    if; 


=    index    +    i; 


end    loop; 


—      ACTIVATE    EDCS    AGAIN    AND    V;AIT    UNTIL    CHILD    DELETE    ITSEF 


rh_out .  comrrand    :=    "tye  ";. 

def_seg    :=    li  t_rrk_5el  (Idt  _tatle  , 

ch_paran(  PR3D0S)  .  5ee;_numter_dat  a)  ; 
def_cff    :=   e; 

rl_def_size    ;=   c  ornand_line' S  IZE/6; 
move_tytes(get_55( ) ,ch_ out 'ADDRESS ,def_5ep,def_cff, 

rl_def_si ze  ) ; 
advance  (ch_pa  ran"' (PRBDOS  )  .  se^_numter_ stack  , 

success    ); 
read_evc  ^  syrc  hr_se2;,    evc_valiie,    success); 
awai  t  (  sy  achr_se^  ,    evr  _value-^l ,    success    ;; 

*  *  :;«  s;: ;;-  -'r.  ^f  -Y-  ;:<  ^?  -•;; :::  *  »;« :;« i'?.  j;*  *  *  si;  ^s  jI^  ^  >;;  ^  ili  i'f.  i\i  i\x.  if.  if.  if  if  if  if  if  if  if  if  if  if  ^c  ;;;  if  if  i'f  if  i'f ;;;  :>f  ;;; ;;; ;;-  >;;  >;; ;;., 

if  if.  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  if  ;;; ;;;  if  ;;; ;;: ;;; ;;; ;;; 

-- -      BEGIN    DELETING    FROCESESS    f^ODUIE 

This   n-odule    eliminates    the   user's   handler   processes    created 

—  to    support    the   active   user   processes,    since   each 
process    required    of    a    specific    nurrter    of    segn-e'^ts    that 
were    created    in    the    CRi ATE_PR0CES5    R'odule  ,    these    will 

—  \e    terrrinated    and    deleted    in    this    step 

prcces    ;='?■; 

while    prores    <    NUM-BER_OF_PROCESS      LOOP 

ch i ld_dele te ( proce s  ,    success    ); 

put_succ(    "child   deleted      ",    success,    w_class    ); 

put_ln(    STDIO_W,    w_cla5S,    "'); 

terTi''ate_se,?rrPnt(ch_pararr(prcces  +  l).seg_nuniher^stack, 

success    ) ; 
terrT-inate_segment(ch_parcn'(proces  +  l).seg_nurrter_data, 

success    ) ; 
t  er  r  i  na  te_  se  p^men  t  {r^h_pararr(  proce  s  +  l).ser-:_nurher_  cede, 

success    ) ; 
delete_5egrent(ch_pararT^(proces-^l).mentor_stack-, 

proces+1  ,  succes s  ) ;      --   delete    entries 
delete_5eerrent(ch_pare.m(proces  +  l)  .!Tentor_data  , 

proces-^5  ,  success  )  ;      —   delete    entries   data 
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delete_5e^nent ( ch_param( proces+1 ) .nentor_c ode , 

proces+6 , success  )  *   —  delete  entries  code 
proces  :=  prcces  +  1 J 

ead  lOOP; 

«l^  kl«  «.''  0#  0«  «i'«  «J<  &1«  «l^  ^l*  «*v  «i<  0«  0«  k^  0«  s''  ^l^  0«  O*  ^'«  «'*  ^^  -k'*  h''  «*«  •>'•'  ^«  «''  0#  •.'«  «)'  •'<  «*«  •>'»  «■«  •.'«  «'#  ■>,'«  «l^  «■«  •■«  «■«  ik>^  «t«  .  t«  h>«  ^«  «l«  .>«  .!«  iit«  ^l>  iJ^  «^«  ,t,  O* 
^_avv         *!•  'I"*  'I*  '(^  'I*  'I*  f    I*  'l*  't*  't*  *t*   'I*  ^^  'I*  '•"*  't*  *!*  't*  'l*"  'I"*  'l*  'I*  *!*  't*  'I*  't*  'T*  'l^  '1*  'I*  *i*  'I^'l*  *!*  *»*  *!*  ^t*  't^  'l*  't*  'l*  '|*  *i*  '|»  'i*  'I*  'I*  '|*  1*  '|*  ')»  '|*  *»*  f*  '("■  '|* 


•  'I*  •'•"'  'I*  '1* 


TERMNATE    SESr^'SNTS   AND    DELETE    SEGMENT    MODULES 

These   rr.odules   will    terrr.inate   and    delete    the    se^rrents 
created    previously    to   hold    the   rentor    segrent   used    to 
create    the   user's    stack    segrrents    and    the   user's   data 
sei^rrents,    and    the    synchronization    segnent    to 
establish    c  onrtiunice  t  ion    anoHft   processes. 


terrrinate   and   delete    synchronization    sef2;nent 


terrrincte_segment  (51, success)  I 
delet e_segment (31 ,11 .success) 5 

terrr:inate   and    delete   irentor    segr^ent 


se^rent  51 
—  entry  11 


terrrinate_se^rent(  31 ,  success  )  ;  --      se^rrent   31 

delete_sef?rrent  ( ini  t .  ini  t  ial_seg(  2  )  ,    5,    success    ); 


'I*  'i*  'I*  "I" 


,   ^^  «^  *j^  ^j-.  ^.■%   «,«  .i.^  «,■•  *,*  *,^  *,*  «,^  *,*  *,^  *,»  *^»  ^jV  <>j»  *_^  *,*  *,«  *,»  •i*  *,*  ^j»  »,N  *|*  ^,»  ^,'>  *j*  *,>  ^1%  *|*i  *,^  *,v  *|%  yli*  ^j%  ^|«  *j<»  *,■*  ^|S  >,»  ^C  * 


END  PROCESS 
put_ln(  STDIO_V;,  w_clas5, 


GOOD  BYE 


); 


—  Infinite  loop  to  prevent  trap.   Could  also  await  an 

eventccunt. 

success  : =  0 ; 

while  success  =  0  LOOP 

success  :=  2  J 
END   loop; 

EN'D  prnain; 
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APPENDIX  B  -  USER  HANDLER  APPLICATION  PROGRAM 

This  appendix  lists  the  L'ser  Handler  Application  Program 
code.  Only  one  program  is  provided  since  the  three  different  programs,  one  for 
each  different  user,  differ  only  in  the  port  used  on  the  RS-232  board,  which  is 
indicated  below  : 

Port  6  User  1 

Port  5  User  2 


Port  3  User 


The  programs  are  called  PUSERl.  PUSER2,  and  PUSER3. 
The  program  listing  for  user  1  is  detailed  next. 
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pragrra    rangechecy:(  of  f )  ;  pragrra   detug  (  of  f )  ;  pragrra 
aritbcheci^(  of  f  ]  ;    pragma    eniirntal  (  of  f  )  ; 

VITH   agate,    a^.atej,    arl,    alit,    alitj,    strlit,    files,    util, 

Drcce ; 
PACKAGE   EOEY    puserl    IS 

USI    agate,    agatej,    arl,    alit,    alitj,    strlil,    files,    util, 
pr  oce ; 

■,<*«■#  «>««>«  *•*  *'*  0«  ••*  *•*  *'*  •'*  «•'  »'*  *•*  *'*  *'*  •'•  *'*  »'*  *'*  »'»*'**'*  «>«  *''  *'••  *'*  »*'  »'*  v'*  *'•  »•*  •'*  *'•  *V  *'*  V*  ^''  ^''  *'*  "'*  *'■•  »'*  *'*  *''  *''  *'*  *'*  »■*»'*  *'*  »'»  »'»  •'*  %'*  »i* 

^^  ^^         *,»  *|*  »|»  ^,»  *|«  *|»  ^«  *j*  *|»  *|«  *|»  *(»  *,*  ^i*  *4'«  *!■*  *|*  *|«  *|«  *,"•  'i*  'i*  'i^  'i*"  'i*  'i*  'i»  'I"  '.*  'i*  'l*  'i'  'i''  'l*  'l*  'l*  't*  'i*  'i*  'i*  'i*  'I*  ')*  'i*  'l*  'l*  'l*  't*  'l*  '(*  'l*  'I*  'I*  'l*  ^*  'l* 

—    Constants  used  ty  the  prograr 


STEIC_1* 
STEIO  R 
10  PORT 


■> 
■> 


peoce: 


--> 


assigns  logical  device  1  to  write 
assigns  logical  aevice  0  to  read 
assigns  the  ports  according  with  the 
follow  detail  : 

puserl   --> 

puser2   — > 

puser2    --> 
assigns  crcess  rumter  l.iil.o  for  ruser 


port  6 
port  t 
port  3 
1,2,3  for 


puser2  and  puser3  respectively 


:  CONSTANT  integer  :=  i; 
:  CONSTANT  integer  :=  ? ', 
:  CCNSTA.MT  integer  :-  6; 

:  CONSTANT  integer  :=  i; 

MrOHY_AVAILA^LE  :  CONSTANT  integer  'r- 
SEG^'rNTS_AVAIIAPIE  ;  CONSTANT  integer 
NUMBER_FFOCESSES  :  CONSTANT  integer  p 


STEIO_V 
STriO_R 
10  PORT 
PROCES'^ 


=  102; 


c  1 


Varieties  used  ty  the  prograrr 


w_cla5S  :  access 

success  :  intege 

ch_ir:  :  input_ 

data_def _size 

def_cff 

def _seg 

ch_evc_val 

pvr_ch_val 

rd_s tr 

us  errarre 

password 

rh_cla  ss 

ch_resource 

eco 

end_pr  og 

ch  access  level 


_class; 

r; 

ssage; 

integer; 

integer; 

integer; 

integer; 

integer; 

string; 

string(8 )  ; 

string(S  ); 

access_c la  ss ; 

child_resource ; 

tcolean; 

toolean ; 

:  level  record; 
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ch_levsl 

entryx 

m  e  1":  t  0  r 

see_rcde 

seg_r-ur"ter 

ch_pardFet ers 


in it  :  rl_proces5_def; 


user_level ; 

in  teger; 

integer; 

se^_acce  5S_  type ; 

integer; 

r l_parameters » 


MAIN 


Eegi 


init    :=   get_rl_lef ( ) ; 


this    sentence    is    olrlisatory 


*•>  V»  s'*  •'-  O*  »'*  »•-  *'*  *'*  ^'*  »'*  *'*  *'*  »'«  %'*  *v  •'•  »V  *'•  %'*  ••**•*  *'^  *'*  *'* 

^^  ^^  'l^  'l^  *l^  'l^  'l^   'l«  't^  ')«  '!'«  ^|«  '|'«  '|«  ',*  »|«  '|«  '|«  '|«  ^1^  ^i^  «|*  *f*0f  #)^  «,«  J,« 


~      ATTACH    TIRMINAL    f^ODULE 


*  'l*  '(^  'l*  't"*  'l*  '(*  'l*  'I^  'l*  ^t*  'I*  '(*  'l*  'l^  *l*  'j*  'I*  'l*  '("•  'i*  *(•  'l*  *("•  'i*  •■p*  '(*  ',»  *|* 


This  rrclule  attaches  port  X  to  its  process  in  order  to 
use  it  in  I/C  operations 
attach  terrinal  as  write  device 

attach_tew(  IC_PORT  ,  STDIO_\a'); 

w_class  :=  ini t  .resources  .!TaT_clas5 5 

attach  terminal  as  a  read  device 
cttech_ter(lC_?ORT,  STDIC_P.  ); 

indicates  that  was  activated  ok 
put_ln(STEIC_*,w_class,"U  S  E  R  "" ) ; 

synchronize  with  the  main  application  (CCP^  to  indicate 
that  it  was  created  ok  and  allow  continued  execution 
usir^  the  await  operator.  It  means  that  the  process  will 
wait  until  the  nain  application  returns  control  to  this 
pr  ocess 


advarce( ini t . ini tial_seg(2) ,  success  ); 

read_evc(  ini  t  .initial_set?(0  )  ,  evc_ch_val,  success  )' 

awa i t ( in  it .  ini tial_seg( 0 ) ,  eve _ ch_val +1 ,  success  ); 


»'*  V'  *';  *'»  *'*  *'*  'i'*  »'■'  *''  «'*  *'*  *'#  fc'*  »**  s''  »'•  **'  •■'*  »'*  *'*  x'<»  n''  *■'»  *''  ^i» 
•l*  'i*  'i*  'l*  ')*  'i»  *i*  ^C   'i"*  'l*  'i"*  'i*  'I*  *i*  ■'i^  *'i"*  'i*  'i*  'i*"  •*!*  'i*'!"*  ""i*  't*  '("" 


y,*  •■,■•  *,-  *,»  »,^  tf.,^  ^,.»  *,*  i,i»  ,,»  ^^,  ,|,  ,^^  ,j»  ,^»  ,^,  5j»  ,|,  ;^c  ;,i  J,i  ;_< 


^:  :;<  i'r  ^ ;;-- ;,'« ;'^  ;',;  =;<  *  j;:  ^'f-  ;^  ;'^ ;;-,  ^^  ~M ;;;  :;s  sis  ;;;  5'^  -.;«  ;;t  >;:  ;;e  ;'^  sj;  jIc  ;;«  ;-^  >;c  ;J: ;;;  ;;«  ;){  s;;  s;:  ^;  ^  ;;s  -;;  ij; :;;  ;;s ;);:;{  ;;«  ;);  :;:  ;;; ;;-  o-  .j.  . 

—      LOAD  -PARAMETERS  MODULE 
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This  Tcdule  assi,2;ns  parameters  to  the  process  that  it 
will  create.  These  parameters  are  renter  nunber,  entry 
nurler,  and  segment  numter,  used  cy    stacic,  code  and  data 

—  segrre-^ts  needed  by  the  rrccess  to  te  created 

—  (ACTIVI  US?R) 

1  oad_par5ml '  ini  t  ,ch_pararreters  )  ; 
load_dCcess_c]ass(init,ch_level ) ; 

end_pro^    :=   false? 
while    net    end_prc^   LOOP 

%'*  »'*  *'*  »'*  »'*  *'*  «>«  «■«  »'*  %'*  *•*  «•»  »'*  «>>  o*  V*  *'*  V^  V'  *'*  *'*  ***  V'  *V  *'*  *'ff  *'*  *'*  V*  *'*  **'  V*  V' V*  ***  V*  **'  V'  *'*  *'•  **»  ^'^  »'»  *'•  *'*  *■'  *'*  *'*  •'*  *''  *V  »'*  •'»  *■*  »'*  *'• 

^H  ^M         *i*  'l"  'l*  ')*  *!"■  *,»  't»  *t^  'I*  'l^  'l*  'I'  'l*  'l*  'l*  't^  'I*  *)*  'I*  •(*  '!*'•*  'l'*  'l*  'l*  *1*  'I*  'l*'l*  'I*  ^*  *l*  '»*^|*  *|*  *|*  *!'*(*  *1*  'l*  'I*  ^1*  'I*  *|*  't*  *|*  'I*  'I*  'l*  '(*  'i*  'l*  '4*  'i*  'i^  'I* 

—  LOOP  MODULE 

This  module  executes ^several  operations  until  the  opera- 
tor enters  the  word  "tye".  This  means  that  the  users  work 
is  finishei  a-nd  termiantes  this  process  execution.  The 
steps  considered  ere  : 

a.-  Clearance  identification 

USIRNA"^P  and  PASSWORD  (lo^in  process) 

t.-  Create  and  nakekncvn  mentor  and  synchronization 
segments 

c-  Load  the  child's  resources  (this  will  be 
subtracted  from  the  parent  resources) 

d.-  Create  child  process  (ACTIVE  USER)  sin^^le  level 

e.-  Detach  the  device  used  for  I /O ,  it  will  be  used 
by  child 

f.-  Synchronize  with  the  child  created  to  indicates 
what  was  created  (US^R  CHILD) 

g.-    S:^'nchronize  with  main  application  prcgram(CCP)  to 
indicate  that  an  ACTIVI  USER  was  created.  In  turn 
COP  will  makeknown  the  segments  that  are  synchro- 
nized with  ACT  IV?  USPE  (45,46  for  userl; 
47, 4F  for  user2,  49,50  for  user3) 

h.-  S.yrchronize  main  with  active  user  and  wait  until 
the  active  user  finishes  his  job 

i.-  fther  ACTIVE  USEE  terminates  his  Job  the  user 
handler  recovers  the  resources  assigned  to  his 
child  and  terminates  and  deletes  the  segments 

—  created  to  be  mentor  and  synchronization,  plus  all 
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the  segments  needed  to  create  the  child 
(loaded  in  step  "b ) 

j.-  Synchronize  with  CCP  to  indicate  that  ACTIVE  USER 
is  not  lender  active 
--   END  LOOP 

clearance  identification 

tlk_scr(STCIO  \v,w_cla5S  ,""  ) ; 

put_str(STDI0lw,y_class  ."USERNAr^E  ")  ; 

eco  :=  true;^^__ 

usernarre  :=  ""; 

usernare  :=  get_inpu t( eco, w_class  )  » 

put_ln(STr'IC_W_^w_clas5  , "" ) ;    —  put  cursor  in  next  line 

if  username  =  '  'bye"  then 

end_prog  :=  TRUE; 
else 

put _str(STDIO_¥,w_ class, "PASSWORD  "); 

eco  :=  false;_^ 

password  :=  ""; 

password  :=  ,set_inDut  (  eco  ,  w_cl  ass)  ; 

put_lnf STDIO_W,w_class  »  ""  )  J 

loclc_for_level^usern  a  ne, password,  ch_level,ch_class); 
create  rrentor  to  the  child  process 

ch_access_level  :=  ch_level(4);   —  min  access  class 

mentor  :=  init .ini t i al_seg(l ) ; 

entryx  :=  31 

nh_class  :=  ch_acces5_level .min » 

—  create  the  mentor  segment 

cr_segment(init,mentor,entryx,ch_class,surce5s); 
if  success  /=  0  then 

put_succ( "success  value  04  is  ", success  ,w_c lass  )  J 

T)Ut_ln(  STDI0_W,w_cla5S  ,  ""  ); 

END  if; 

—  makekncwn  this  segment 

seg_mode  :=  r_w; 

seg_numter  :=  3i; 

mk_segment(init,mentor,entryx, seg_ number , seg_mcde , 

success  ) ; 
if  success  /=  0  then 

put_sucr  (  "success  value  !?4  is  ",  success  ,  w_class  )  ; 

pu  t_  In  (STDIO_>/,w_  class  ,  ""  ); 

END  if; 

ch_access_level . min  :=   ch_access_level  .max ; 

—  single  level 
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load   the    resources    that    the    child    will   have 

merrory        — >   60      (    forrat    E24) 
segments   — >   100 
processes    ->   0; 


ch_resource.mernory    :=   r,EI^ORY_AVAILABLE; 
ch_resource  .segments    :=   SEGr-'ENTS_ AVAILABLE; 
ch_resoi:rce  .processes    :=   MJ^'EEE_PROCESSES  ; 


—      SYNCHRCNIZATION    :    code    segment    will    te   used    to 

synchr.  parent  and  its  child,  tut 
init ial_5eg(2)  is  used  to  synchr. 
child    with   main   application   program- 

cr_proce5s(init,ch_parareters,ch_access_level, 

prccess,ch_resource,init .initial_seg(2; .success; ; 
ifsuccess/=0then 

put_ succ( "success   value   06    is    ", success ,w_class ^ ; 

put_ln(ST!5IO_V,w_cla5S,  ""); 

ENi  if; 

read_evc(ch_parameters.seg_num'ber_code, 
ch  eve  val, success  ); 


detach_device(  STDIO_V.' ,  success  ); 
detach_device(STDI0'R,  success) ; 

await (ch_paraneters.seg_num"fcer_c ode, ch_evc_val+l, 

success ) ; 

synchronize  with  main  application  program  to  create 
segments  to  hold  stack  and  data  (will  te  used  as  synchr 
segrrents  with  the  new  process) 


def_seg  :=  li t_mk_sel( Id t  tahle , ini t  .ini t ial  5eg(3)); 
def_off  :=  0;  '  ■      ' 

ch_ in . inpu t_ one  :=  username; 
ch_in  .1 nput_resul t  :=  ""; 
ch_in.input_class  :=  w_class; 
da ta_def _size    :=  (input_message 'S IZE/e ) ; 
move_ty tes(get_ss( )  ,  ch_in 'ADDRESS  ,  def_seg,  def_off, 

da  ta_def _5i  ze  ) ; 

synchronization  process 

advance( ini t .ini tial_seg(3  )  ,  success  ); 
advance(ini t .ini tial_seg(2  ) ,  success  ); 
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read_evc(init . init ial_sefi'(0)  ,    evc_ch_v5l,    success    ); 

await(    ini  t  .ini  tial_seg(?  )  ,    evc_ch_val -^1 ,    success    ;; 

read_evc(ch_parerTeters.seg_rumter_cod8, 
ch_evc_val , success    ); 

advance  (ch_parameters.seg_nurrter_stack,  success  )  » 

will    await   until    child    self   delete 

await(ch_pararreters.seg_num'ber_code,ch_evc_val+l, 

success  ) ; 

if  success  /=  ^>    then 

put_succ( "success  value  12  is  ", success ,w_c lass ) 5 
put_ln(STriO_W,w_ class  ,"'"); 

ENE  if; 

attach  I/C  terminals  again  and  delete  segments  created 
creeted  for  the  child  process 

attach_tew(IO_PORT,  STriO_'A}  ; 
attach_tFr(  IO_FO?.T  ,STI)IC_R); 

delete  segments 

terriinate_segrrent(  ch_pararreters.5eg_nurTiter_5taci<:, 

success  ) ; 
terrrina  te_segrrent(  ch_parameters.  seg_numher_code  , 

success); 
termina  te_segren  t(ch_para!Teters.seg_nuiTter_data, 

success ) ; 

delete_ segrent (31, ch_para me ters.entry_ stack, success'; 
d  el  ete_  segment  (31,  ch  _parameters.er.  try  _dat  a,  success  "*; 

t erminate_segmen t (31 ,  success);   --  terminate  mentor 
d el ete_ segment (init .initial_seg(l) ,3,success^; 
child_delete(PROC]rss-l  .success)  ; 

communicate  with  main  application  program  to  delete  the 
segments  to  held  stack  and  data  that  were  created  to 
synchronize  main  with  child 


def_5eg  :=  1 i t_mk_sel ( Id t_ tatl e , ini t .i ni t ial _seg( 3 ) ) ; 

def_off  :=  0; 

ch_in . input_one  :=  user name; 

ch_ in . input_result  :=  ""; 

ch_in . i npu t_clas s  :=  w_class; 
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data_def  _si  ze    :=  (input  rressage 'S  IZE/5) ; 
rrove  l>  t  es  (^et  _s  s  (  )  ,  ch_i!i 'ADDRESS  ,def_ses  ,  def_cff, 

data_lef_5ize  ); 

synchronization  process  ,  the  control  will  return  to 
main  application  pro2;ran',  CC? 

advance(init.initial_set'?(3),  success  ); 
advance(init.initial_se^(2),  success  }; 
read_evr- (  ini  t  .  init  ial_se°;(0  )  ,  evc_ch_val,  success  )» 
await(  ini t .  in  it ial_see^2  )  ,  evc_ch_val  +  l ,  success  ); 

end  if; 


end  loop; 

synchronize  with  rnain  application  pro,s;rafr  to  tell  that 
the  user  no  longer  will  use  the  terminal 

def_se£r  :=  1  i  t_mk_sel  (Id  t  _  ta  tl  e  ,  i  ni  t .  ini  tia  1  _se£;(  3  ;  )  ; 
cef_off  :=  0; 

ch_in  .  inpu  t_one  :=  usernarre; 
rh_ in  .  i npu t_result  :=  ""; 
ch_ in  .  input_clas s  :=  w_cla5s; 
data_def  _size    :=  (ini-ut_rre5sa,?e 'SIZE /8  ) ; 
rrove_ty  tes  (get_ss(  )  ,  ch_in 'ADDRESS  ,def_se^  ,  def_off, 

data_def_si ze  ); 

detach_device(  STDIO_R,  success;; 
detach_device(  STDro_V,  success  ); 
advance 'init. in  iticl_sefe' ''3),  success  ); 
seif_deiete(  i-^i  t .  ini  ti  al_se^(  2  ),  success  ); 
if  sui^cess  /=  0  then 

attach_tew(IO_?ORT,    STDIO_V;    ); 

put_succ ( "successor   is   ".success,    w_class); 
END   if; 

END    iDUseri; 
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APPENDIX  C  -  ACTIVE  USER  APPLICATION  PROGRAM 

This  appendix  lists  the  Active  User  AppHcation  Program 
code.  Only  one  program  is  provided  since  the  three  different  programs,  one  for 
each  different  user,  differ  only  in  the  port  used  on  the  RS-232  board,  which  is 
indicated  below  : 

Port  6  User  1 

Port  5  User  2 

Port  3  User  3 

The  programs  are  called  PRCHLl.  PRCHL2.  and  PRCHL3. 
The  program  listing  for  user  1  is  detailed  next. 
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pragrra    ran^echeckC  of  f  )  ;  pra^ima   detug{off); 
pragpa    arithcheck(  of  f  )  ;pragrra   enumtat(  of  f  )  ; 

WITH  agate,  agatej,  arl,  alit,  alitj,  strlit,  files,  utii; 

P/^CKA:iE  BOEY  prchll  IS 

USr  agate,  agatej,  arl,  alit,  alitj,  strlit,  files,  utii; 

«^  «■«  k'«  *>«  «*«  hI«  «>«  *J#  W#  «■«  «^  »A>  «*«  s*«  ^«  «^  ^t'  «*•  •'^  ^^  *'?  *''  «^  ^*'  V*  V*  \''  *''*  *''  *'f  *'tf  ^'*  ^'f  ^  ^^  ^^  ^^  V'  ^'^  V'  '''^  ^'  **f  ^'  ^''  V'  «'^  ^'  V'  ^'  ^*«  ^'  ^*  ^»   «''  « 
^^  ^^  «fv  *l*  *!•  *|»  *|*  *y»  *j*  *f»  *|*  *f»  *|%  •f*  *|*  S(«  *^*  '(*  *f»  »p  »|*  Sj*  *i%  *p  *|*  *[•  *|*  ^»  ^*  *|*  *r»  ^*  *|»  *f»  *|»  ^t»  *^  ^|«  *p  *|«  "^  *f*  *^*  *f»  *|t  *!•  S|*  ?|*  *|t  •!*  ^  *(%  *|*  ^,»  ^«  «f«  *|«  « 


Ccrstants  used  ty  the  nrcgrarr. 


STDIO  !*■ 

--> 

STDIO  R 

--> 

10  FORT 

--> 

assigns  logical  device  1  to  write 
assigns  logical  device  2    to  read 
assigns  the  pcrts  according  with  the 
following  detail  : 

puserl  -->  port  6 
puser2  --";  port  5 
puser3   -->   port  3 


st:ic_v' 

STDIO _n 
10  PORT 


CC.'^STANT  integer 
CONSTANT  integer 
CONSTANT  integer 


i; 
0; 
6; 


varieties  used  ty  the  program 

w_class  :  acce5S_class ;  . 

success  :  integer; 

ch  in  :  input_nessage > 


data_def_size 

def_of f 

def _seg 

evc_ch_val 

rd_  str 

ecc 

end  prog 


integer; 
integer; 
in  teger; 
integer ; 
string; 
to  clean; 
toolean; 


init  :  rl _process_def ; 

—   MA  I N 

Pegir 

init  :=  get_rl_def ( ); 


this  sentence  is  otligatory 


fct^  *i*  »•*  «)«  ^t,   fci,  »'*  *'*  »<*  &i«  ^t*  *'•  %'*  «<«  «t«  »'*  »'*  >J«  »',.  *'*  »v  *''  *''  *'*  *'r  V'  *''  *''  *'*  *'tf  *'c  *'*  *'*  **'  V*  *■'*  *"'  V**  *''  *'*  V*  V*  *'*  *''  *'*  *''  "*'*  *'*  *''  V'  *'*  *'*  ■•''  *V  *'"  *'' 

^^.^^         7|^  *|'^  *i%  *i»  #|«  «!«  »|>  *|%  #,*  ♦,■>.  *,*  *,»  *|*  *(»  *,»  »|*  ^4*  ']»  *|»  *|*  *|*  ',»  *'|*  '4*  *|^  ^1*  ',»  *|*  *(■»  '(*  'i*  *|*  '(*  *i*  '1*  'I*  '|*'l*  'i*  1*  'l*'|*  'I*  'I*  *|*  'l*  'l*  'l*  't*  'P  'i*  '(^  *l*  'l*  'l*  'l* 

~   ATTACH  TERMINAL  MODULE 

This  rrcdulr  attaches  port  X  to  this  process  in  order  to 
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use    it    in    I/O    operations,    the   device   will   have    the    sarre 
clearance    that    the   process    has 

w_clas5    :=    ini  t  .  resources  .rriax_class  ; 

—  attach    terminals    (read    a'^d    write) 
attach_ter(    IO_PORT ,    STDIO_R    ); 
attach_tev(    IO_FORT,    STDIO_'a'    ); 
put_ln(STDIO_'f  ,w_class,"USEH    CHILD    "); 

—  Syncronize    with   USER   HANDLER    to    indicate    that    it    was 
created    ok   and    let   him   continue   his    execution   using    the 
advance,    and    await    operator    {advance   User   Handler 

—  evertccunt    to   continue,    and   await    to    stop    its   process 
and    returns    the   control 

advance' in  it. initial_seg(l), success); 
read_evc(irit.initial_seg(0) ,evc_ch_val , success / ; 
await(init.initial_seg(2),evc_ch_val-^l,success); 

;1;  ;;:  sj: ;;:  i,i  ;;;  -r  -.^  -r  'A^  ■,-  -,• ;!'  ^'fi ',- '','  ',<  si'  ^  :1;  :r  =1=  ',' ','  ',•  >\:  >',=  5;;  =1^  :|;  ;1:  >;;  5;:  5;;  ;;; ;;:  >;; ;;;  ^s  ;);  ;;: ;;:  ;;c ;;;  ;;t  J',;  ;;c  ;;;  5;;  :',:  ;;;  s;; ;;;  ;;;  ^:  ;;; 

~'x  •',: :;: ;;-.  v- ;',:  -.s  ','  i'.-  J.-  ;!=  ;;:  5;;  5l;  s;^  :',:  ;;:  ;;:  =;:  'A-  -S  •','  i'.i  i'fi  i'.i  5;<  >;«  i'fi  i'fi  i',i  s'.S  i\'  i\<  i\i  i'fi  i'fi  i'fi  >',;  5'.;  J',: ;',:  s'.s  >;;  >;; ;;;  ;;«  jji  s;s  >;«  j):  ;;; ;;;  ;;{  ;;j  ^: ;;; 

—  LOOP    MODULE 

This  module  executes  several  operations  until  the 
operator  enters  the  word  "tye"  that  means  work  is  done 
The  steps  considered  are  : 

a.-  Put  prompt  ("'•=)")  indicating  that  is  ready  to 
accept  ACTIVE  USER  input  messages 

h.-  Get  the  user's  input  message 

c-  Load  input  message  entered  ty  the  user  into 
segment  data  used  to  pass  the  information 

d.-  Synchronize  with  main  application  program  CCP 
waiting  for  the  answer  to  the  message  sent 

e.-  Display  the  result  of  the  message  after  it  was 
processed  ly  CCF 

~   END  LOOP 

eco  :=  true; 
end_prog  :=  false; 


while  net  end_prcg  LOOP 

^et  input  messages  from  the  terminal 
rd  str  :=  ""; 


put_5tr(STEI0_Vi,w_class,"-)  "  ); 
rd_5tr  :=  ,2et  input  (ec  o  ,w_class  ) ; 
put  ln(  STriO~W,  w  class,  ""); 


put  the  cursor  i 
the  next  line 


def_ 
def_ 
ch_i 
ch_i 
ch_i 
data 
move 

if  ( 
e 

else 


se^  :=  lit_mk_sel ( Id t_tdble  ,  init . ini tial_5e^(? ) }  ; 

off  :=  0; 

n.input_one  :=  rd__s_tr» 

n . i  npu  t_resul t  :=  " " ; 

n.input_cldss  :=w_classi 

_def_size    :=  (input _message 'SIZE/S) ; 

_tytes(set_ss( ) ,  ch_in 'ADDRISS ,  def_seg,  def_off, 

data_def  size); 
(rd_str  =  "lye")   or  (success  /=  ?: )  )    then 
nd_prog  :=  true; 


tegin  the  synchronization  process 

advance( init . ini tidl_seg(3  ) ,  success  ); 
adven ce ( ini t . ini tial_seg> 2 )  ,  success  ); 

read_evc  (i  ni  t  .initidl_se,^(0  ;  ,  evc_ch_val,  success  ;; 

await (  init.initial_seg(?),  evc_ch_val+l,  success  ); 

display  the  answer's  messa=:e  that  was  transmitted  ty  CCP 

def_seg  :=  lih_mk_sel ( ldt_ tatle , ini t . ini tial_se^(3 U ; 
def_off  :=  e; 

data_def  size    :=  (input  message 'S  IZIVS  ); 
rrove_tytes  (def_seg,  def  _cf  f  ,^e  t_  ss  (  )  ,  ch_in 'ADDRESS  , 

data_def _si  ze ) ; 
put_ln(  STDIO_V,  w_class,  ch_in . input_resul t  ); 

erd  if; 

end  loop; 

>'*  «'*  »'«  *•>  »•*  ^'i*  V'  *'*  »*'  *'*  *''  >'*  **'  >'*  V'  *''  •'''  *'■*  **'  *'*  V'  ^''  V'  *'*  **>  **'  *''  *''  *''  *'*  *'■*  *'*  *'■'  *''  *'*  *''  *'•  v'*  *'*  »'*  »'.»  ***  *'*  »'^  s'*  *'»  »'••  **^  *'^  *'■»  »'*  *'*  s'*  O*  *'*  »'* 
,»  *!'*  *|H  *|*  *,»  *,*  *(*  <»i*  ^*  *|*  *-|**  >,■*  *|»  >|*  *|»  *[■*  *|*  *|*  *|*  '|»  '(»  *(*  »,■»  ',^  ^i*  *|*  ^1*  *|*  '1*  *"!*  *|»  *|*  y,*  *,*  ^|»  *(»  *|»  *,*  *(*  >j*  »,%  ^1*  *|*  *,'*  «|«  ^j*  *|*  *|»  *j*  ^i"*  ^,»  *|*  J,*  *,%  ^,^  *,* 
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i'rJf :;: j;; ;;;  ;;s :;: ;;;  s;:  i\i ;;j  :;<  sj;  ;;;  >;; ;;; ,;;  ;;;  ,;:  5;<  s;;,;; ;;-  };. ;;.  ,;-  ,;. ;;; s;- :;.  ,;; .;.  o-j.j  J.-  ,,,  5,„..  j,j ...  .,, ... ... ... .,, J,, .,, ,,, .,, ,,,  .,, ,., ,,  ,,,  ,,^ ,  ^ 

—  DETACH  TERMINAL  MODULE 

This  rrcdule  returns  the  device's  control  to  the  user 

—  hardier 

detarh_device(  STDIO_R,  success); 
detach_device(  STDIO_W,  success  ); 

5;;  i'f  5;: ;;:  >'r  -'.i :;-;:  :;<  i'fi  ::s  ;N  -r  ':i  J'.i  i|:  Jr  i'.i  i'r  i\i  >i»r  'fi  i'fi  i'fi  -.<  =',:  :!=  j1-  'fi ',-  sN '',« -fi  >;-  :;j  5;< Jls  sji  sis i'fi  !'.<  i'.i  i'fi  >\i  i\i  i\'.  i[i  ^';  '.'r  -,'  ^fi  i\i :',?  i'.i  jU 

:;c  i',i ;;:  ;;s ;;; ;;; :;;  5',;  s',: ;;;  >;j  :;:  >;;  :;j  sis  sis  5|s  sis  sis  s;e  sis  sis  sis  si;  si?  sit  sic  i[:  i\i  ;l!  i\c  >',t  >,i  >1;  ;ls  jls  >l:  ;it  3I;  si;  ;1:  :1:  ;1;  si;  >l!  slj  ;1;  i[<.  ;l<  ;l;  ;1;  j;; ;;« ;1: 5I;  ;1; 

—  SELF  DELETE  MODULE 


__     rn 


This  irodule  tern-:inates  the  child  process  (ACTIVE  USER) 
ar.-d  advances  the  eventccunt  of  the  se^rrent  indicated. 
In  this  case  it  is  the  se^rrient  used  to  synchronize  with 
his  parent  (user  handler) 

5elf_delete(  ini t .  ini tial_seg(  1  ),  success  ); 
if  success  /=  0  then 

ettach_tew(  IC_PORT  .  STEIO_V.  ); 

put _succ( "successor  is  ".success,  w_clas5); 
END  if; 

;nD  prchli; 
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APPENDIX  D  -  PRBDOS  APPLICATION  PROGRAM 

This  appendix  presents  the  application  program  used  to 
simulate  the  behavior  of  the  BDOS  operating  system.  Because  of  time  constraints 
this  program  only  has  code  that  shows  the  process  that  should  be  performed  when 
BDOS  in  invoked,  simulating  the  result  in  order  to  pass  it  to  the  CCP  process. 
This  program  is  called  PRBDOS,  and  its  listing  is  next. 
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pragma  ran.gecheck(  of  f )  ;  pra^tra  deti:g  (  of  f  ) ; 
pragrra  ar  ithcheck  (  of  f  )  ;pragrra  enumtat  (  cf  f  ^  ; 

WITH  agate,  ag^tej,  arl,  alii,  alitj,  strlit,  files,  utii; 

PACKA:;!  body  prtdos  IS 

USi^  agate,  agatej,  arl,  alit,  alitj,  strlit,  files,  i:tii; 

«ttf  ^l'  «*'  ^'•*  «''  ^^   U*  «*«  ^*  v'i*  ^^  «'f  «*>  vV  «)#  «'«  >'*  «l«  O*  ^l>  0««t#  0»  «l^  «Ltf  0«  «l«  «**  «^  «*'  ^>«  0«  *■'  ^'«  v<«  «l#  V«  V*  'Jf   «<«  «•«  kl^  «'#  ^«  «t«  «>#  «J>  «■«  «i«  kid  «■«  «iU  «Ji«  >.l^  .t< 

— ^    ^,i»  *,*  *,^.  *,-»  o^*  4^  7f^ ;,%  *,,  *,*  *,•  *f  *|*  ,p  *^  *,«  3,,  *,*  *^,  3,,  *,*  ^  ^»  *,% ,,,  ^,  *,*  *^,%  *|*  ,,*  ^,  ,,^  *^  3,,  ^%  -p  jf.  5;%  *,c ;,; ;;;  ;j;  ;,c  5;s  >p  >^  5i<  3,?  ;^  ;js  ;,i  ^  y,<  ;js  ^x 

This   prograrr    only    sirrulates    the    tehavior   of    the    BDOS 
work,    in    order    to   handle    "disk    files" 

»'*  «*'  *'*  %0  *'<  *•*  »►*  »'*  »'*  fc'*  *"^  «■«  •<«  «l^  *'^  »'*  *'j"  -^f  «ii^  »'*    ^';2C  5  i  Si  s's  *V  Vs  i's*'*  *'*  ^''  *'*  %'f  »'*  »'f  k'rf  *i*  «ii*  »,'•  «t^  k*^«V  »'*  V*  *'*  *'d  *'^  *'#  *'*  »'*  »'*  »'*  s"*  x'»  «>* 

™»  ^  -1^  'l*   '|>  ^l"^!*  •^^  'l"*  n*   'I*  't*  'l^   'l*  '1*^1*  'l*'l^  'I^  "%"*  'C  'l'*     'I**!      '•      'I*  'l*  '!*•  '»*  'I* 'I*  *i*  *!*  '(*  'l*'l*  *1*  *1*  '("'i*   'l^'l*  '1**1*   *t*'l*  »!*  'l*')"   'i*  ^1*  'i*   ^l"*  "i"  *i*  *|*   *|» 


constants 


STDIO_V' 
STEIC_H 
10  POET 


CONSTANT  integer 
CONSTANT  integer 
CONSTANT  integer 


=  i; 
=  0; 
=  3; 


~  MAIN 

w_class  :  access_class > 

success  :  integer; 

data_def _5ize  t  integer; 

def_cff       :  integer; 

def_seg       :  integer; 

evc_ch_v5l     :  integer; 

ch_ccrrrr    ;    c  ona'-.d_l  ine  ; 

end_prog      :  tcolean; 

— file_data      :  files_data; 

— .seg_head      :  segrr.en  t_header ; 

— spg_data      :  segmen t_data ; 

in  it  :  rl_process_def; 


Begin 
ini  t 


get_rl  def (  ); 


attach  terminal  as  write  device 

w_class  :=  in i t  .resources  .max_cl ass ; 
—  attach  tew(  10  FORT,  STDIO  W); 


*j*  *(»  *(%  *|*  *i*  *!•  *(* 


*,«  *!■•  »,%  *,^  *,^  *i«  *|>  *,»  *|"«  *,*  *,*  *p  ?,»,  3j»  »,»  3,*  ,|»  *|k  2|«  »|»  *,>.*,*  *,»  *,*  >,*  *|^  r|«  ^,<*  *,%  »,«  ,j,  *|^  ,|^, 


'  i';  i*r  V*  s'*  i'f  I'f  s''  *''  *'■•  •'''  "''  ••'*  *'"  *'*  »'•  *'*  *'*  k'* 

•  'P  'l*  'i"*  'i*  'i*  'i*  '(k  'i*  'i*  *!"•  *■!*  *|*  »|*  *|*  *(»  *.»  *.%  «|« 


initialize  directory 
put  ln(STEIO  W,  w  class,  "BDOS 


I  1 
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JU  *J^   M*  «^  **f  ^*f  «''  «'«  ^'^  ^''  ^^  *^  ^*  *''  ^^  "^  *''  ^'^  V'  V'  ^V  "'^  ^V  **#  V'  V'  ^''  ^'*  ^'^  ^'*  *f€  ^"^  ^'  *V  ^'^  ^''  ^''  *''  V'  ^'^  ^'  ***  ^''  ^^  «V  ^'  *^  ^'  ^'^  ^*  ^'  «V  ^1^  V^  ^*' 
^  ^tm  *(•  '(*  'I'  *i*  *p  *i*  *i*  *i*  *i*  *r»  *i*  I*  ^*  'I*  *(*  'I*  'I*  *i*  'I*  n*  'n  1*  *i*  *!*  •p  *»■*  '^  *l*  *»*  *l*  '^  '»*  ***  *t*  1*  •<*  l(*  *t*  *(*  *^  'I*  *Ti*  *1*  T*  'I*  'I*  ^P  *1*  *P  *i*  '1*  *^  *t*  *f*  *t* 

Synchronization  with  CCP  to  tell  that  it  was  created 
without  troulle 

tegin  the  synchronization  process 

advance ( init . ini tial_seg(2 )  ,  success  ); 

read_evc( init.initlal_sefi;(2) ,evc_ch_val, success  ) ; 

await(  ini t . initial_se^(0 ) ,evc_ch_val  +  l  .success  ); 

—   PROGR/^M  'A'AITS  UNTIL  THE  CONTROL  IS  PASSID  FROM  CCP 

«lv  -J*    ^'    -k*'  «*'  <>*«  «1<  «*«  «■«  V'  ***     ^'  ■'*  ***  ^t    ^'  ^V  V'  ^'^  ^''  ^*'  *'V  **f    *^*   '^*'  ^'^  V'  ^'  ^'  V*  ^^  ^'  ^'  ^'  ^*  ^'^  ^l^kV  ^f*    -^f    V*  ^«  >■>'>  «■«  aV  <^*'  «''  «''  *^  ■«''  ■>''  «*'  "'^  ^*«  «'• 

^K  ^M        »^  't*  'i"*  *!*  •»•*  ^t*   *|«  '1^  *(•  '1*  'I*  't*   'I*  'p  *l*  ^^  n*  ^*  'p  'l^  'I*  'I*  t*  *|*  *f*  1*  'P  ^^  *(*  ^^  T*  *|*  *p  ^p  •p  *!*  'P^P  *!*  *!*  *!*  1*  1*  'l*  *n  *■(*  'I*  11*  'I*  1*  *l*  'I*  'I*  1*  1* 

end_pr02  :=  false; 

«■•  «l«  «><  ^1^  K*'  «>#  0>  «!'  0«  "J'  "^'^  oi^  \V  ^'  ^*'  <^  "^f  *'^  "^  ^''   ^''  ^*'  "^  ^'*  ^'  ^''  V'  '■^  ^*'  ^''  "''  ^*'  ^"^  ^''  *''  ■>''  ^''  "■''  '*''  ^*'  ^''  l''  «*'  ^'^  «''  «'*  «-*>  «>'«  •*'  •>*'  «'>  ^''  '«''#  0«  *l« 

^B  ^       'i*  '!»  *t*  'i^  *;*  *!*  ^^  1*  'P  "^  ***  1*  t  't"*  'i*  'P  'P  'P  'P  'P  ^^  1*  'i*  'P  "^^  'P  "^^  "^  'i*  'P  'P  'P  'P*P  *P  ^i^  'P  *l*  *P  ^*  'P  'P  *\*  'i*  'P  'i*  'P  'P  O*  'P  'P  1*  t*  'P  'i* 

Be^in  loop  until  CCP  sends  "tye" 

while  not  er.c_prog  LOO? 

,2-et  corrrand  line  passed  "ty  CCP 

def_se^    :=  lib_rrk:_sel  ( ldt_table  ,  ir.i  t  .init  ial_se^(3  )  ) ; 
def_off    :=  0; 

data_def_size  :=    (corrand    line 'SIZE/6  )  ; 

move_tytes  (def  _seg,  def  _  of  f  ,^et_ss  (  )  ,ch_ccmrr 'ALDRESS  , 
data_def _size ) ; 

put_ln(  STriO_V',w_class  ,    ch_c  orrrr  .conmand  ) ; 

if    ( ch_cornrr  .corriTand    /=    "tye  ")    then 

IF    ch_comm . command    =    "create      "    TEIN 
ch_corT]rr.  result    :=    "file    created"; 

create_f ile( ) ; 

FLSIF  ch_comm  .c  ommand^  =  "delete   "^^then 
ch_comm . resu It  :=  "file  deleted"; 

delete_f ile( ) ; 

FLSIF    ch_comrr .  c  ommand    =   "renaire      "^then 
ch    comm . result     :=   "file    renamed"; 
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rename_f ile( ) ; 

EISE 

ch_corT'n' .  result  :=  "rress.  processed  "*♦ 

IND  if; 


load  the  result  to  pass  it  to  the  parent  process 

def_seg  :=  lib_mk  sei (ldt_tdtle , ini t . ini tial_ 5eg(3 ) ) ; 
def_off  :=  0; 

data_def_size    :=  (comard  lire 'SlZi'/e)  ; 
nove_'b.ytes  {^et_ss  (  )  ,ch_corfr!  'ADDRESS  ,def_se^,def_off, 
data_def _size) ; 

5;:  5',;  ^': ;;; ;;:  i\i  ;;;  ;;<  i^i  i'fi  ^j  ;;;  >;<  j;; ;',; ;;: ;;;  i\t  sis  5);  s;;  s;?  i'fi  ;;;  5;;  ;',;  ;;;  5;;  i\i  i',i  5,; ;;;  sjc  i\i  i\i  i',i  3;;  i\i  i\:  j;; ;;;  ;;;  5;;  j;j  ;;;  ;;: ;;;  ;;c  5;;  ;;;  ;;; ;;; ;;:  3;;  ;;j 

Synchronize  process  with  CCF  in  order  to  cass  the 
resul t 

5dvance(init .  ini  tial_se,s(2  )  ,  success  ); 

read_evc(  ini  t  .  init  i  al_se^  (0  )  ,  evc_ch_val,  success  ) ', 

awai t (ini t . ini tial_se^(0 ) ,  evc_ch_val+l ,  success  ); 


else 

end_prog  :=  truej 

erd  IE; 

erd  LOCP; 


**>  *■'  v'f  *■>  »i*  >i«  *•*  V»  »•*  *'*  O*  V»  *■'  *'*  *'»  *•*  *'*  »'*  »•*  *'*  V'«*'  V>  *'*  *'*  V*  »'*  »'•  *''  v'* 
•^  ^~        '1^  'l^  '1^  Ol^  '■«  ^t*  'P  '1^  'I*  '1^  '1^  't^  ')^  '1^  "1*  't*  'I*  'I*  'I*  'I*  '1*^1^  '1^  '1^  '■**  'C  '1^  ^i"  'f*  't" 


'l»  'I*  *,*  *,^*J*  *,»  ^,^ 


*,*  ^^•ti  3,»  »,*  *,i  ^j*  . 


End    of    the    prC|E;rarTi   and    self   deletion   process 

—  detach_device(  STDIO_R,  success); 

—  detach_device  (  STDIO_V(',  success  ); 

self_delete(  ini t .  ini tial_seg(  2  ).  success  )> 
if  success  /=  0  then 

attach_tew(IO_PORT,    STDIO    >• )  ; 

put_succ ("successor  IS  "  ,succes s  , w_clas s ) ; 
END    if; 

EiND    prtdcs; 


69 


APPENDIX  E  -  COMMON  PROCEDURES  UTILITY 


This  appendix  contains  the  procedures  and  functions  used  to 
provide  information  when  the  system  primitives  are  used.  These  were  obtained 
from  the  demonstration  program  provided  by  Gemini  Computers  Inc..  and 
modified  to  reflect  a  generic  use  by  the  application  programs  developed  in  this 
research.  The  programs  are  "PROCE.LIB"  (contains  the  specifications)  and 
"PROCE.PKG"  (contains  the  code  developed). 
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WITH  a^ete,  agatej,  arl,  alit,  ali^j,  strlit,  util,  files; 

PACKAC-I  BOEY  prcce  IS 

USy  agate,  agatej,  arl,  alit,  alibj,  strlit,  util,  files; 

—  Ccnsta'^.ts  fcr  device  slots. 


5TTIC_V  :  CONSTANT  integer  :=  i; 
STEIO_R  :  CONSTANT  integer  :=  0; 
IO_PORT  :  CONSTANT  integer  :=  0; 

—  Constants  for   segments. 


—  port  v"   for  main 


SIZE  r^ENTOE 


:  CONSTANT  integer  := 


*^  i?;  I'i  i!i  i!i  ^*  ■**•  **•  ***  V*  ^  *^  ***  *••  *•*  ^  *^^  *'*  ***  •■'•  *f'  •^*  *V  «>*  ••*  *•*  »•»  *■»  «>»  »i*  ^'^ 


1 ;    --   size  rrent  or 
—   synchr.    segrrt 

5'*  *'»  *'*  ^'*  *'*  »'*  *'*  »•*  «y  «■«  «irf  *',»  «■«  »t,  »t,  ^1^  »t^  »i^  ,1^  , 
(■•  'i*  >(*  *(*  *i*  »,*  *|»  ^1*  »|^  *,*  «,«  *,«  «,^  *(,«  *,*  ^,*  »,*  *,.»  Jji  * 


—  FROCIDURI    CxR_SEGMINT 

This  procedure  completes  the  pararreters  needed  ty  the 
prirri  tive"  crea te_segrren t  .  The  record  structure  is 
descrited  in  the  file  "agate. lib"  provided  ty  C-eriri 
Computers  Inc. 

—  The  Daraneters  received  ty  this  procedure  are  : 

initial  process  definition 
indicates  the  segment  number  tnat 
will  be  carent  of  this  new  segment 
indicates  which  entry  numter  of  the 
mentor  is  used  to  create  this  segment 
indicates  the  security  level  of  the 
segment  to  be  created 
output  veriatle  that  indicates  the 
result  of  the  operation  after  call 
the  primitive 

This  rroceduce  is  used  to  create  the  mentor  and 
synchronization  segments 


ini  t 

~> 

ment  cr 

—  > 

entryx 

—  > 

class 

—  > 

success 

—  > 

PROCIDURE  cr_segment(  init  :  in  rl_process_def ; 

mentor   :  in  integer; 

entrx    :  in  integer; 

class    ••  in  access_class; 

success  :  cut  integer  )  IS 


cr_seg_str  :  creat e_seg_st ruct ; 
w_cla5S  :  access_class; 

5SGIN 
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ENL 


w_class  :-  init  .resources  .min_class » 
cr_se2;_s  tr  .rrentcr  :=  rrentor; 
CT    seg,_siT  .ev.lryx    :=  entrx; 
crlse^_str. limit  :=  SIZE_MIM0R; 
CT_seg_5tr. class  : =  class; 


create_ segment (  cr_5e6_str,  success  )? 
if  (  success  =  817  )  THIN 

put_ln(  STEIO_W,  w_class,  "917   means  segment  already 

exists."  ) ; 
ENC  if; 
cr  segment; 


a)#  ^)*  ^>  *'^  *'^  '«'«  ^U  *0  «l«  «*'  «*•  «'*  V*'  «*«  «l«  «''  ^'^  ^''  S*'  «''  ^^  ^'  ^'^  V'  ^''  «''  ^'^  ^^^  ^V  **f   ^'^  **'  •^  *''  *''  ■''  ^''  ^'  ^'*  «''  •'''  «*'  ***  «V  ^«  O^  (J^  %'•  ^^  k>«  «*«  «*«  w'^  «l^  «<#  o^ 
a^  ^K        «,«^«  ^^^^  #|b  ^1%  <r|%  «f*  ^^  #^«**,'*  «,<■  «|«  «|«  ^S  ^%  *,*  *|«  ^|«#|%  ^|%^|«  *|*  *!••  *|«  #1*  ^ifr  «|«^^  *,*  »|«  r|*  l*^*  'K*  *|*  *!**!*  *|*  #f»^^»|«  »|««|«  ^«»,«^|«  *,»  ff%^f»  *^  «|*#^  «>j«  rf*^f* 

«'*  *'*  ***  ••*  V#  «*«  *'*  *'*  *•»  »'-  *'*  *•*  »'•  *'*  ^ 

^B  ^—         'i*  'l*  *l*  •»*  *|*  'i*  'i*  '.^  *t*  't*  'l*  'i   't*  1*  * 

—      FRCCIDURF    DI_SEGME[vT 

This    x-TOcedure    completes    the   parameters    reeded    ly    tne 
primitive   d elete_segment .    The    record    structure    is 
described    in    the    file    "agate. lil"    provided    ly   Gerrini 
Computers    I nc  . 


The   parameters    received    "by    this    procedure    are 


init 
men  tor 

entryx 

c  la  ss 
success 


—  > 

—  > 

—  > 

—  > 

—  > 


initial  process  a ef init ion 
indicates  the  segment  number  tnat 
will  "be  parent  of  this  new  segment 
indicates  which  entry  numter  of  the 
mentor  is  used  to  create  this  segment 
indicates  the  security  level  of  the 
segment  to  te  created 
output  variable  that  indicates  the 
result  of  the  operation  after  call 
the  primitive 


1 


PRCCEDUP.E  dl_segment  (  init  :  in  r l_pr ccess_def ; 

mentorx  :  in  integer; 
seg_nunber  :  in  integer; 
success  :  out  integer  )  IS 

mentor,  entryx  :  integer; 
w_class  :  access_class; 

BEGIN 

w_class  :=  ini t .  resources .min_cl as s ; 

mentor  :=  mentorx; 
entryx  :=  seg_numl:er; 

del  et  e_segmer  t  (    mentor,    entryx,    success    >S 
E'ME    dl    seg    tst; 


92 


*!f  2?£  S!i  si  ife  ^  *'*  ***  ***  5?*  V*  **f  5!ff  »*#  **•  *•*  *•*  »**  *■*  »^*  **•  •■•*  ■*'*  *•■•  *'"  ■*»■»  *''  *''  *''  *•*  *>-  -''  *'*  *■'  *'*  s**  «■*-  ■»'*  ~'-  O*  ^.-it  ^U  o-  «."*  >Ui.  1*1*  *l*  »i*  .Jrf  O-  «i-  »i-  o,.  ^i-  .1-  ^1- 

—  —  'r  '*i*  ^*  nr  1*  1"  *r  *-!•  o"  *r»  'i*  'i^  n^  *»*  -ft*  'i*  i*  *t»  •(*  '!■»  'i*  'i*  -nr  i*  *»■•  '»*  'i*  'i*  n*  'f  'r  'i*  i*  n*  ^**  'i*  V  t-  'i»  'i*  'i*  'i*  'fi  ^  'r  ^*  -r  'i*  'r  V  *»*  'I^  'r  V  'i* 

»■*  *''  >'?  ^'^  *'*  *'»  v'*  *'*  k'*  O^  *'»  %'rf  »'*  «i*  «■«  «)»  fc'*  •.'*  «1#  *'«  *'*  »'i*  %'f  *'^  »i*  »,ij.  »'*  •i'^  0»  «l«  •'«•  s''  *''  *'*  *'#  »'*  *'*  »'*  Vi*  »irf  »'*•'*  «i*«i«  *'*  *'*  *'i«  *'»  «<>  »'*  »'*  «■«  «■«  «•«  «■«&■« 
aaa^M  'l^  'I*  'I*  't*  ',"*  'i''  'I*  '1^  ^1*  'i*  'i^  '1*  'p  'i*  'i*  'I*  *i*  'i*  'i*  'p  'i*  'i*  'I*  'I*  '(■*  'I"  'i**  'i*  '1^  'i""  'i*  'i*  'i*'!*  'i»  *i*  'i*  *i'  'i^  'i*  'i*  '(»   '(•  *■,»  *,*  ^j-*  *(*  ^,»  ?|*  *|»  *|»  ?,*  5,»  »|»  *,»*,% 

-■ -      FRCCIEURE    r^K_SEGMINT 

This    procedure   con"plete5    the   pararreters    needed    ty    the 
prirritive   nakeknown_se^n-en  t  .    The^^record    structure    is 
descrited    in    the    file    'achate.  1  it"    provided    ty    ^emini 
Cofrputers    Inc. 

The  pararr^eters    received    ty 


ini  t 

rren  t  or 

ent ryx 
nurr  ter 
mode 
success 


—  > 
\ 


—  > 

—  > 

V 


this  procedure  are  : 
initial  process  definition 
indicates  the  se^rrent  nurr  ter  tnat 
will  te  parent  of  this  new  se^rrent 
indicates  which  entry  nunter  of  tr.e 
mentor  is  used  to  create  this  se^rnent 
indicates  the  nurrter  that  the  sesrre^.t 
will  have  in  the  LLT 
indicates  the  kind  of  sef^rer.t  that 
will  te  created  (r_w,  r_e,  etc.) 
output  variatle  that  indicates  the 
result  of  the  operation  after  call 
the  prirritive 


This  proceduce  is  used  to  makekrown  the  rrentor  and 
synchronization  segments 


FROCirUEF  rrK  se^rent  ( 


init  :  in  rl_prccess_def; 
mentor   :  in  inte^rer; 
entrx    :  in  intep:er; 
nurrter   :  in  integer; 
mode     :  in  se^_access_type; 
success  :  out  integer  )  IS 


seg_rec  :  f^k_kn_s  truct ; 
seg_ret_rec  :  mk_kn_return ; 
w  class  :  access  class; 


EEGIN 

w_c la  ss 
5e^_rec 
s  e  fT  _  r  e  c 
5eg_rec 
seg~rec 


:=  ini t . resources .min_class ; 
mentor  :=  mentor! 
entryx  ;=  entrx; 
se,t'_numter  :=  numter; 
seg   mode  :=  mode; 


seg_rec .prot_level  :=  tyte(  1  ); 
se^  rec.^ate  numter  :=  NULL  INEJX; 


■ring  1  protection 
—  Qo  gate 


93 


seg_rec .gate_prot    :=   tyte(    2    ); 
mak:ekncwn_5e,e;ment    (    seg_rec,    seg_ret 
EMr   mk   segrrent; 


rec,  success  ); 


.  ^«  *,*  *,■*  *,•  *^» 


^'^  %l«  «'^  0«  ^^  ^'  ^'  O'  «^>  ^'^  ^^  ^#  ^^  ^''  %''  ^'  ^*<  ^''  ^'' 

'I*  'i*  ■'r*  T*  'I*  'i*  'p  ^1*  'i*  *»*  '1*  'I*  '»*  '»*  •**  n*  1*  1*  'i* 


•.Id  «■«  k'>  «<«  k.1^  O^  ^If  «'<>  »'•  O'  «''  x'*  «^'  «''  K<«  «l^  «■«  «■«  «■«  «*^  «'^  *'«  O^  «l*  «!'  h'*   Vi*/  «''  «*'  ^''  •>'•«*'  »''  s''  "''  ^''  «''  **'  «''  *'*  «''  *'^  «V  *''  ^''  ***  *''  ^''  *''  *'•*  *''  ^''  ^''  * 
■   ^        5|C  #f«  -fj*  ^-k  >,%  5,^  *,.  .»,»  *j%  >j*  J,*  >,.  ^,«  >r«  'J*  *(5  *f%  'i**\*  *»*  ')**T*  '**  *1*  *(^  'I*  '»*  ***  '»*  't"  'i'  "t"  '»"  'l*  'I'  •»*  *!**»*  'I*  *!""»*'»*  '1*  'l*  *(**!*  'l*  'l*  *(*  *t*   'I*  'i*'!"  ' 

—   FROCEriRE  MAKE_KNOl(tN_S^NC 

This  procedure  effects  several  actions  related  to  the 


creation  of  special  se^rrents 
application  program  with  the 
sefjrrents  were  created  hy  the 
will  only  nakeknown  those  in 
swaDin    these    in   rrerrcry 


to    synchronize    the    main 
active   user.    Since    the 


active   user 

its    own    LIT 


this   Tjrocedure 


tatl' 


and 


The  paranieters  received  ty  this-  procedure  are 
init  — >  initial  process  definition 
ch_uara     — >   indicates  the  uarareters  u" 

_  r  T  P  a  t  P  t.  b  p  n  c  p  r  b  ;:i  n  -^  1  P  r  T^  r 


ch  "uara 
ch_class  — > 
ch_active  — > 
c'n.   user  sync  —  > 


_  ,  _  .  jsed  to 

create  the  user  handler  process 

indicates  the  access_class  of  the 

se^nent  to  te  created 

indicates  which  active  user  is 

trying  to  cormunicate  with 

is  an  output  record  tnat  contains 


trying  . .  .  _ ..  _ 

an  output  record  tnat 
the  segment  nurrlers  assigned  to  the 


success 


—  > 


synchronization  segments 
output  variatle  that  indicates  mc 
result  of  the  operation  after  call 
the  primitive 


the 


This  prcceduce  is  used  to  rrakeknown  the  synchronization 
segments  fmein  application  -  active  user) 


FROCIDURI  make  know  sync { 


init  :  in  rl_>:roce3S_defi 
ch_para  :  in  r  l_i!arameter  s  » 
ch_class  :  in  access_class» 
ch_active  :  in  integer? 
ch_user_svnc  :  out  users_dct ive » 
success  :  cut  integer  )  IS 


mentor  :  integer; 
entryx  '■    integer; 
seg_mode  :  seg_access_type ; 
see-'_^umter  :  integer; 
class     :  acce5S_class; 

BEGIN 
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mcke   knov/n    root    se^rrent    (code    segment    of   each   child) 


rrertor    :=   ch_para  . seg_runber_ccde; 

entryx    :=   3; 

seg_nurrter    :=   ch_para  .  s,yr.chr_chll_rrentor» 

5eg_rrcde    :=    r_w; 

class  :^-   ini  t  .resources  .min_clas5; 

rrk_5e^ment(init,rnentcr,entr,vx,seg_nurr'ber, 

5e^_mode , sucres 5 ) I 
if  success  /=  3  then 

put_succ( "success  value  ??6  is  "  ,  su ccess  ,ch_cla ss  )  ? 

put_ln(STi:iC  W,ch_class  ,  ""  )  ; 
end  if; 


rrake  known  stack  segment 

mentor  :=  ch_para  .  s.y  ncbr_chld_nentor  I 
entryx  :=  i; 

seg_num'ber  :=  ch_para  .  sy  nchr_chld_5t  ack  ? 

seg_mode  :=  r_w; 

mk_segn-ent '  ini  t  ,ment  or  ,  entryx  ,  seg_nu.Tter  , 

seg_mcde , success ) ; 
if  success  / --   2    then 

put_succ( "success  value  0C7  is  " , sucres s  ,  ch_c  la ss ) ^ 
put_ln(STI}IO_W,ch_class  ,"""); 
end  if; 

make  known  data   segment 

mentor  :=  ch_para . sy nchr_chlG _ment or ; 
entryx  : =  2 ; 

seg_numter  :-  ch_para . synchr_chld_da ta ; 
ses_mode  :=  r_w; 

mk_segrrentCinit,mentor,entryx,5eg_numter, 

seg_mode,  success!^  ; 
if  success  /_7  0  then 

put_5ucc(  "success  value  2C.9    is  "  ,  succes  s  ,  ch_r-id  ^s  )  ; 

put_ln(STDIO_W,ch_class,""); 
end  if; 

ch_user_sync(ch_active)  .seg_data  :  = 

ch_pard.synchr_chld_data; 
ch_user_sync(ch_active) .5eg_ stack  := 

ch_para.synchr_chld_ stack; 

5wapir_segment(ch_user_sync(ch_active)  .sef--_data  , 

success ) ; 
—   read  event  counts  of  each  segment 

read_evc(ch_u5er_sync{ch_active).seg_datd, 

ch_user_5ync{ch_active}  .evr_data,suc'"ess)  ; 


95 


terminate_sei2;ment  (44, success)  ; 
if  success  /=  ^  then 

pu  t_5urc( "  success  value  ?A2,    is  "  .success  ,ch_cla  ss  )  » 

put_ln(STCIC_W,ch_class,  "")  ; 
end  if; 

INE  make  knew  sync; 


«<«  «l«  •Xr   kl^  »>»  ^«  «'«  %'«  ^^  *A#  «1«  *f«  0«  0«  kl«  k*«  «l#  0«  »(•  «il»  **4  «^  «il«  «(•  «■«  «*•  «*«  ^«  0«  «JI«  *il«  »l«  «l^  0«  *t«  *■«  *l^  O^  «l«  ^l*  V*  «)«  «*•■  O*  0«  kl«  «0  «l«  «l^  «1«  *l#  «l«  »0  «J«  O*  kI« 

^  ^     'n  'c  •»*  *p  n*  *!*  *i*  •■•*  *i*  'p  *i*  t*  *»*  *i*  *t*  •»»  *i*  •!*  *i*  I*  *i*  *if*  "i*  'I*  'I*  •!•  *i*  ^r  *i*  *!'  '(•  'I*  *r  *i*  'i*  'p  '•*  i*  *p  *i*  •»•  '^  't*  •»*  'i*  '*»  *i*  '»•  t*  'i*  *p  *(•  *»•  *»*  'r*  't* 


}'^  ^**  *'*  %'*  %'*  %'#  *•*  ***  %  «  »'*  *'*  %,* *  %**  <'*  *'#  ***  %}0  %'^  %'*  ^'jf  »'*  *'rf  ***  %'*  *"*  *'*  %'*  **#  *'*  *'^  *'^  *'*  *'#  *'^  *'*  *'*  •'#  *•*  %'^  »*'  ***  *'*  »'*  *'*  *'*  »'*  %'#  »'*  *•*  %■*  »**  «'tf  %i*  «i^  *■> 
|«  *|*  *)»  *|»  J|»  ^1*  »|«  *,*  *|*  Jj*  *,•  *,*  *,*  *_*  *,*  *,»  *,*  *,»  «,V  *,*  *(»  *,*  *»,«  *,»  *,*  *|«  *,«  *,*  •*,*  »,*  •■,»  »,*  *,•  *|«  *,»  *,%  #,»  ^,*  *,*  *,»  *,*  *,*  »|%  ».%  *,»  *,»  •j*  i»  ■*  V|»  *!■»  *,%    *  «  ^  »  #,«  ^« 


—  PROCICUP.E    TrRMINATI_S^NCHR_SFG 

—  This  procedure  terminates  ti^e  se^^ments  rr-akeknown 
prex'iously  with  the  otject  to  synchronize  the  rorrrunic 
tier  tetween  an  active  user  ar:d  the  rain  apul  .  prCi^rarr. 

The  parameters  received  hy  this  procedure  are  : 


ini  t 
ch_para 

ch_class 

success 


— >   initial  process  definition 

—  >   indicates  the  Daran-eiers  used  to 

create  the  user  handler  process 
— >   indicates  the  access_class  of  the 

segment  to  te  created 
— >   output  variable  that  indicates  the 

result  of  the  operation  after  call 

the  primitive 


—  This  proceduce  is  used  to  delete  the  synchronization 

—  segments  created  "before  (maifi  -  active  user; 


FRCCECURE  termine te_synchr_ seg(  init 

ch_para 
ch_class 
success 


:  in  rl_process_def ; 

in  r l_pa  r aret  ers  ; 
:  in  a c c e  s 5 _ c 1 a  s 5 ; 
:  out  integer  ;  IS 


terminates  the  segments  created  to  synchronize  main 
application  program  with  the  process  created  ^y  the 
child  process  leaving  availacle  the  segment  numlers  in 
~   the  LPT 

BIGIN 

t erminate_segment ( ch_para  .  synchr_chld_da ta ,  success  ); 

termina te_ segment ( ch_pa ra  .synchr_chld_stack  ,  success  ); 

END  terminate  synchr  seg; 
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***  **^  *'^  ***  ***  *'*  *'#  ***  ^^*  »'*  ***  »'*  *■*  ***  ^'^  %**  *■*  ^'*  %<^  *l^  *'rf  fc'^  *l*  %*>  %'*  ^1*  %'rf  ^**  fc'*  v'*  ^'*  ***  ^'*  *'*  *'rf  **rf  ^'*  *'#  %l^  ^*^  %l*  %k^  «  «  *^*  fc^^  ***  «^^  v'^  *** 
m  ^^  'l^  'l^  '1^  't^  '1^  '1^  'l*  'l"  'l^  'l^  'I"  'l^  'l''  'P  'l^  'l*  'I*  'l"*  '1^  't^  'l*  'l^  'l^  'l^  't^  'l^  '1^  'l'  'l^  'l'*  'l*  ')'*  'l*  'l^  'l^  'I**  'l^  't'*  'l^  'l^  '1^  'l^  'l*  'l**  'l*  'l**  't^  'I'*  'l'* 


«<«  V*  *•*  V*  ***  *"'  *•*  *'*  *'*  *'*  *'*  **'  ^'^  *'*  *''  "**  ■*•  ***  *^  *'*  V'^V  ***  ^'  *V  ^'^  "i**  *'*  **•  V'  »'*  *■'*  ^l**"*  »A*  *•*  *'*  »>*  x'<  v'*  »•*  *4*  *•*  »'«  v'»  *•*  %•«  kt*  »,>>  <.(«  %■«  H**  »'*  O*  ■»•• 

.^^     #■,> ^*  *t*  n* "t*  1* 'f*  1*  'I*  '\*'i''  'I*  'i"  I*  'r*  -^^  1*  'I*  I**!*  o"**!*  't*  "1'*'^  "i*  ■*»■•  '^^'r  o*  '!■■  *t*  ^x^^i*  f  ^  'i^-^*  'i-"  'i*  'i'"i»  'i*  'r  *t*  i*  o"*  ^i*  'i»i*  V^'-i*  'i*  'i' 

—   PRCCII^URZ  ?ILL_INIT 

This  procedure  fills  the  process  definitior.  record  with 
the  data  provided  in  the  initial  process  definition  plus 
the  resorces  that  the  parent  will  pass  to  his  child  and 
the  access  class  of  this  specefic  process 


The  pararr.eters  received  "by  this  procedure  are 


ini  t 
ch_ini  t 
ch_resource 

success 


—  > 

—  > 
\ 

— > 


initial  process  definition 

output  process  definitic 

indicates  the  resources  parsed 

parent 

output  varialle  that  indicates 

result  of  the  operation  after  ' 

the  prirritive 


its 


he 
11 


PRCCEDUfti 


def  • 


fill_init(  in  it  :  in  rl_process_u:n:i, 

ch_init  :  out  rl_process_def; 
ch_resource  :  in  child_rescurce ; 
ch  access  :  level  record  )  IS 


fill  in  the  initial  process  record 
process  called  ly  crt _proc_ ts t . 


of   a    child 


PEG  IN 
ch 
ch 
ch 
ch 
ch 
ch 


init.cpu    r=   in 
init.num_cpu    : 
init.nun_kst    : 
ini  t . r 00  t_ac  ce 
in  it .  s_see?    :  = 
_ir.it.  resources 
ini  t 
h2  4  frrn    irte^er( 


ch 
ch' 


in  it 
in  it 


.  resc 

.  res  0 


urces 

u  r  c  e  5 


it. 
=  i 
=  i 
ss 
3; 
.pr 
.  re 
ch_ 

.pr 
.se 


cpu; 

ni  t  .nurr_cpu* 

ni  t  .nun':_k:st  * 

:=    init.root_access; 

i  0  r  i  t  y    :  = 

sources  .pri  ori  ty  ;    — sarre    as    parent 

re  source  .rremory , 

r  h  _  i  n  i  t .  r  e  5  0 11  r  ■ :  e  s  .  n  e  m  0  r  y    )  ] 
ccesses    :-   ch_resQurce .processes* 
i^mnts    :=    ch_resource  .s  earner  t  s  5 


this   will    he   modified    with    the   specific   access    c-lass 
of    each    process 

ch_in it . resources .min_class  :=  ch_access  .min J 
ch_init. resources. ma j_class  :=  ch_access.iTax; 
ch    init.rin^    nun    :=    tyte(    1    ); 
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ch_init.sp2 
ENL  fill  init; 


=  e; 


«*^  *■*  *'*  %o  fc'^  %■«  ***  »'rf  %l>  %l^  ^1«  **#  %*^  «'^  ^'^  %'^  **#  *'*  %•*  ^'rf  ^*^  ***  *^*  %'*  *'*  ^'^  ^'*  ***  fc'*  %'*  %*^  *'*  *''  *'*  * 
»f»  ^l«  #l«  *l«  «|«  ^1%  ^|«  ^,H  «|X  #|«  y^H  «|«  «|«  «|«  ^1*  «|«  «|^  ^|«  «|«  #!<«  >|«  V|«  «|«  «|*  r,«  «!«  '|k  «|«  ^1*  r|S  ^^^  *|«  «!<•  «|*  a 


»•*  *'*  *•«  *'^  »'*  »'*  %'*  ^'rf  »'*  »'•  *'*  *'*  %'*  O*  ***  *'*  *'>  *'*  *'»  *•*  v'*  *'*  »'*  \l*  *'*  V*  *'*  ■*'**'#  »'*  *'*  **•  »'#  »•*  «'*  *•*  ***»'*  «*«  »t*  ^'#  «'«  »t«  fct*  O'  »'i»  O*  «■«  «'«  «*ir  «l^  »'*  kO  *'*  *'*  ■»'« 
'1^  'l^  ',<  '1^  '1^  '|'«  '|«  ')«  'l^  'l^  ')«  '1^  'l^  'I*  'l*  'l^  'l^  '|0  '1^  'l^  'l^  'l^  'l^  'l*  'l^  'l^  'l^  'l*  'l*  'l^  'l*  'l*  ')>  'f^  ',*  'l^  'l^  'l^  'i**  ',•  'l^  'i^  'I**  ',«  ^|V  ^|«  ^_«  .r,%  «,%  «|S  if, «  V,*  ^,  «  iTi^  ^,«  v,« 


—      PFOCIDURS    Cli    FkOCESS 


__  m 


This    procedure   performs    ell    the    operations   necessary    to 
create   a    chill    process,    this    operatic'^s    include 
FakekncwQ    the    rode   sediment    of    the   child,    credtion    of 
stack    and    data    se^^r^ents,    fill    the   addess    space 
specification   and   process    creation 


The   parameters    received    \.y    this    prccedure 

...  V....'.  t^.. 

mit        — > 
ch  "oar 


process 

ch_resource 

synchr_seg 

success 


N 


initial  process  definiti 
parameters  to  create  a  c 
(segment  nurhers , en t ry 


re    I 
on 
hi  Id 


—  >      indicates    the   process   riumLer 

user 
that 


created  (example  active 

indicates  the  resources 

child  will  have 
—  >   indicates  the  se^^-ment  th 

to  synchronize  this  new 

its  parent 
— >   output  variatle  that  ind 

result  of  the  operation 

the  primitive 


t  D 


\9 


dt  is 
p  r  0  c  e- 

icate 
after 


0:1 1" 

used  . 
b  s  wit  h 

5  the 
call 


PROCEDURE  cr_prccess(  init  :  in  r 1 _proce5S_def ; 

ch_par     :  in  rl_parameter5* 
ch_access  :  in  level_reccrd^ 
proces   :  in  integer; 
ch_resource   ;  in  child _re5 ource  ; 
synchr_seg  :  in  integer; 
success  :  out  integer  )  IS 


chld_seg 
ch_ini  t  : 
seg_rec  : 
segl_mkn 
sefzl_ret 
crt  rec  : 


rl_sec:_struct ; --  rl_addr_ar  ray  for  child  ■  segmen  t 
rl_process_def ;     —  rl_process_def 
creat e_seg_struct ;  —  used  to  create 

mk_kn_s t rue t ;  —  used  to  make  known 

mk_kn_return ; 
rl_cp_struct;       —  create  process 


for  child 
stack  se^~ent 
stark  segment 

structure 


ch_seg_list  :  seg_array; 
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ch_inpt_rr!e5S  :  ir.piit_rre5  sage  i 
datd_def  _size  :  i^.teger; 
end_rhld       :    tcolean; 
w_class  :  ccce5s_cldss ; 
evc_ value  :  integer? 
5tack_5i2fe  :  integer? 
seg_mgr_'by tes  :  integer? 
def_off  :  integer; 
def_seg  :  integer? 
rl_def_size  :  integer? 
dumm,v  :  integer? 

—  constants  for  deterr^ining  stack  size 

rl_stack_5i2e  :  CONSTANT  integer  :=  ie#AF?#? 
vect_size  :  CONSTANT  integer  :=  4? 

EIGIN 

wclass    :=ch    access. m in? 


rr.entor    :=   ch_i;ar  .rent  or_c  ode?    —   appl.    root 
entryx    :=   ch_par  .entry_CDde ? 
seg_nunter    :=    ch_par  .  5eg_':'U[rter_c  ode  ? 
seg_mode    :=   r_e? 


segl_rrkr:  . 
segl_nikn. 

segl_rrikn  .seg_nunter 
segl_rkn . 
segl_n"kn  . 
segl_rl'Cn  . 
makeknown 
if    succes 

put_su 

put_ln 
ENE  IF? 


seg_moae    : =   r_e i 
prot_ level    :=   tyte(    1    )? 
gate_nurT:ber    :=   NULL_IND>[X? 
_segrrent(    segl_mKn,    segl_ret 

c  /-  ?\     t.  hpn 


—  '^0  gate 
success  ) ? 


s  /j;  0  then 

cc("success  value  is  ", success  ,w_cla5S  )  ? 

(3TriO_'A'.w_class,""')? 


address    spec    for   child's    stack 

chld_seg.  spg_nurrter    :=    ch_p5r  .  seg_nurnter_s  tack? 

chld_5eg . se2_mode    :=   r_w? 

chld_seg . swapin    :=   TBUS? 

chld_s eg. protect    :=   tyte(    1    )? 

crt_rec  .  rl_acdr_array (    2    )    :=    chld_5eg? 

address    spec    for    child's    code 

chld_seg  .  seg_nurnter    ;=    ch_pcr  .  seg_r]urr'ber_c  ode  ? 

chld_seg. seg_mode    :=    r_e? 

chld_seg.  svapin  :=  TRUF? 

chld_seg. protect  :=  tyte(  1  }? 

crt_rec  .r  l_addr_array (  1  )  :=  chld_seg? 

address  spec  for  child's  mentor 
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chld_seg.  5eg_nurrter    :=    synchr_seg» 

chld_5es  .  se^_rT'cde    :=   n_a; 

chld_seg.swapin  :=  TRUE; 

chld_seg. protect  :=  tyte(  1  ); 

crt  _rec  .rl_addr_array  (    2    )     :=    chld_sefi;; 

address    spec    for    trap    haadler    se^rrent 

chld_sep:.seg_nurrter    :=    iri  t .  ini  t  ia  l_seg '4)  ; 

chld_seg.  seg_r!ode    :=   r_e: 

chld_seg.swapin  :=  TRUi; 

chld_seg .prctec t  :=  tyte(  1  ); 

crt_rec . rl_addr_array(  4  }  :=  chld_se^; 

address  spec  fcr  child's  data 

chld_seg  .  se,s_rumter  :=  ch_par  .  seft_nur"ter_i  at  a  ; 

chld_se^. ses_rode    :=   r_w: 

chld_seg .swapin    :=   TRUE; 

chld_se^. protect    :=   tyte(    1    ■; 

crt_rec  .  rl_addr_array  (    3    )    :=   chld_sef?; 

fill    the    order    in   which    the    se^rrents   will    te   passed 


ch_seg_list(0) 
ch_seg_list ( 1 ) 
ch_seg_list(2) 
ch_seg_list (3 ) 
ch   seg'list (4) 


=     ch_par  .seg_nun"ter_stack; 
=      ch_par.seg_r.urrcer_code; 
=   syriChr_seg; 
=   ch_par . seg_numler_data ; 
=   init  .initial    seg (4) ; 


••   ^  .  .  TN  " 


calculate  required  stack  size. 

(in  the  future 'will  calculate  based  on  data  in  "C^D' 

file  header  tut  now  just  use  ccr'stant.) 

seg_rrgr_'bytes  :=  (  stack  header 'SI  ZI/6  )  + 
(  init  .nurr_kst  -  (  kit _en try 'SIZF/c  ;)  + 
(  kst_header'SIZr/S  ); 
stack_5ize  :=  rl_stack_size+vect_si7e+seg_mgr_ty tes 

(  rl_process_def 'SIZE/8  ;; 

create  and  make  known  child's  stack  segnent 

seg_rec .mentor  :=  ch_par  .ment or_st ackj 
seg_rec . ent ryi  :=  ch_par  .eatry_s tack ; 
seg_rec . limit  :=  stack_size  -  W 

Seg_reC  .  class   :=  Ch_aC  cess  .max  ; ;;c5;c-^; ;;;;:;;;« :;::;::;: 

create_segment (  seg_rec,  success  ); 
if  success  /=  0  then 

put_succ ( "success  value  aa  is  ", success ,w_class ) > 

put  ln(STEIO  W,w  class,""); 
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IND  if; 

segl_mkn  . men  t or    :=   ch_par  .rren  t  or_s  tack; 
segl_mkn  .  entryx    :=   ch_T;ar  .  entry_st  ack; 
segl_n"kn  .  se^_numter    :=   ch_par  .  seiS;_nunter_s  tack; 
seftl_rrkn  .  seg_rrode    :=    r_w; 
segl_rrkn.prot_level    :=   tyte(    1    ); 
segl_mkn  .gate_nurrter    :=   MULI_INrix; 
se^l_pkn  .^ate_prot        :=   "byte(    0    ); 
makekncwn_se^n-ent  (    se^l_rrkn,    segl_ret,    siiccess    ); 
if    success    /=  0    then 

put_succ ("success   value    a    is    ", success , w_cla ss) ; 

put_ln(STDIO_W,w  class,""); 

IND  if; 

swapin_segrent  (  ch_par  .  se^_num"ber_stack  ,  success  ); 
if  success  /-  0  then 

put_succ(  "success  value  I  is  ", success , w_cldss ) ; 

Dut_ln(STriO  W,v_class,""; ; 

FMD  if; 

create   and   rrake   knowr.   child's   data    se^rrerit 


se^_rec . 

sef:_rec . 

se^_rec . 

5es_rec . 

create_5 

if  succe 
put_5 
put~l 

IND  if; 

se^l_rrkn 
segl_n-kn 
segl_mkr 
segl_mkn 
se^l_rrkn 
se^l_mkn 
segl_rrkn 
makekn  cw 
if  succe 
put_s 
put'l 

IND  if; 

swapin_s 
if  succe 

put_s 
put_l 

FND  if; 


nentor    :=    ch_par  .rrent  or_da  ta  ; 
entryT    :=   ch_par  .en try_data ; 
liF'it    :=   input  _rressage 'SI2F/e; 

class       :=     Ch_aCCeSS  .rraX  ;  ;;;:::5;j ;;-.>;::;::;: :;-.;;-, 

egr^ent(  seg_rec ,  success  ); 

ss  /=  0  then 

ucc("5ucces5  value  cc    is  ", success , w_cla ss 

n(STDIO    W,w    class,""); 


.  seg_niode    :  = 
. prct_level 
.  ga  te_nuiT"ber 
. ge  te_pro t 


.mentor    :=   ch_par .men t Gr_da ta; 

.entryx    ;=   ch_par. entry_da ta  ; 

.seg   rumter    ;=   ch_par  .  seg_num"ber_dat  a  ; 

r_w; 

=    t,yte(    1    ); 

:=    NULL    IN dfx; 

:=  tyteT  0  ); 
r:_segment(  segl_mkn,  segl_ret,  success  ); 
ss  /=  0  then 

ucc("success  value  c  is  ",  success  ,w_cla  ss  "^ ; 
n(STDI0_W,w_clas5,""'); 

egment(  ch_par .  seg_rrn']:er_data  ,  success  ); 
ss  /=  0  then 

urc{"success  value  d  is  ",  success ,w_class ) ; 
n(STDI0_W.w_cla5S, " " )  ; 


fill  in  childs  rl_pr ocess_def 

fill_init(  init,  ch  irit,  ch  resource,  ch  access  ); 
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determine  segment  S.  offset  of  rl_prccess_def  initial 
rec  ord 

def_seg  :=  lit_mk_5el(  ldt_ta"ble, 

ch_par .  seg_nu'n"ber_starV:  ); 
def_off  :=  5tack_size  -  (    vect_size  +  5ef^_m^r_t.y  tes  -^ 
rl_proce5S_def 'SI7I/8  ); 

move  ch_init.  into  proper  place  in  child's  stack  segment 

rl_def_size  :=  (  rl  pr  ocess_def '  31 ZF.  )/e; 
move_'bytes(  f:et_ss(T»  ch_init 'address ,  def_seg,  def_cff, 

rl_def_size    ); 

fill    in    rerrainder   of   create    process_st mcture 


—   skip 

off; 


crt_rec.ip  :=  12S; 
cr  t  _rec . spx  : =  def _ 
crt_rec.spl  :=  stack_5ize  -  ( 
crt  _rec  .  sp2  :=  2  ', 
crt_rec.vec_seg  :=  O; 
crt_rec . vec_of f  :=  steck_5i7e 
crt _rec . chiid_num  :=  proces-1 
crt_rec . pri ori ty  :=  ch_init.r 
cr t_rec .mer ory  :=  ch_init.res 
crt_rec . processes  :=  ch_init. 
cr  t_rec  .  segrrn  ts  :=  ch_init.re 
crt_rec.rrin_class  :=  ch_irit. 
crt    recT/ax   class    :=   ch    init. 


orr-men 

--    se 

vect_ 

no   r 

rl   a 

-   ve 

escur 
0  u  r  c  e 
resou 
sourc 
resou 
res  ou 


d  file  header  (6?  he:0 
t  childs  stack  p 
size  -r   se^_n-:'r_h 
ins  2  stack 


cin  te  r 


,  »r  :5  ,'1 


ddress    array 
c t    size; 


elerr^ent    2 


ces.priority; 
s .nenory  ? 
rces  .  processes  J 
es  .  segmn  ts ; 
rces  .min_class; 
rces .  Tiax    class* 


read    event    count    so   we    know   when    child   has    self_deleted 

read_evc  (  synchr_seg,  evc_valiie  ,    success    ); 

create    the    process 

creat e_proces5 (  crt_rec,  success  ); 
if  success  /-  0  THEN 

put_succ(  "  create  process  success  =  ", 

success,  w_class  }; 
END  if; 

END    cr_process; 

END    proce; 
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WITH'agate,  a^atej,  arl,  alit,  alitj,  strlil,  util,  files? 

PACKAGE   proce  IS 

USr  a^ate,  a^atej,  arl,  alit,  alitj,  strlit,  util,  files; 


«V  V'  *^'  ^''  *^  ■''  ^^  «''  *^  "^  '*''  "'*  "■''  >''  *■''  ^''  '«''  ^''  «''  \''  *«*'  ^'^  ■^'  '«''  ■>''  ^'i*  ^^  ^'^  ^''  "i^  '■*■'  ^''  ^*'  -'•■  ^''  ^*  ^'^  *■''  ^*'*  *^  >''  ■•''  lA^  «''  >-'«  ■>''  ■•''  <^'  ^'^  -^•'  * ''  '«*«  ^''  «*'  ■>*' 

^^  ^^    >|\  *(*  ^i*  ^1*  *^  *(»  *f»  ^,*  *|»  "i"*  '(*  *^  "«i*  ^i*  *i»  *i»  'i^  *(■*  *(»  ^j*  *,*  'i»  '(*  »^»  >i*  *i*  'i*  •'i*  ^i'"  ifi"*  *)■»  *|»  •'[»  ^,^  *)»  ^1%  *i*  *>*  'Tj*  'I*  *|»  *(■«  «^  ^«  *^^  *(*  *i»  ^»  *j»  ^|>  *,*  »,■•  >|»  *,»  *(* 


—      THIS    PROGRAM    IS    PROCE.LIB 


ontains    the    specif  ica  t  i  ens   r.eeded    ty   PRCCI.PKG   prOfsrarr 


«>«  •■■*  O*  *'*  ki>  *'*  «t>  «>«  ^l>  «>#  %}f  «'rf  »'*  •'*  *•*  O'  »'*  *'*  *•*  »•»  *'*  *''  *''  *''  *'*  *'*  *''*  *''  *''  *'■*  *'*  *''  *'*  *'*  *''  «V  *'*  *''  *'■*  *'•  *'»  *'*  *''  ■*'*  »''  «'*  »''  »''  »'/  *''  ^''  •'•'  •''  ■*'  ^'' 
^B  ^       *,*  ^,*  *-!*  *,*  *,*  #1*  *,<•  3)*  *,*  #j»  ^i^i  *,»  ?,»  ?,*  ^j'-  *,%  5|%  »,*  5,*  ^,«  'i*  'i*  'i*  'i*  '(^  "(»  'I*  'I*  'i*  'I-*  't*  't"  'P  'i*  *i*  *i*  't*  'I*  'i*  'i*  »i*  'i^  'i"*  'I*  'I*  'i*  'i*  'i*  'I*  "I*  'i"  'i*  *!"  '.*  1* 

PROCEDURE  cr_segment(  init  :  in  rl_process_def ; 


rrent  or 
ent  rj 
class 


in  inte^^er; 
in  in  te^er; 
in  access  class? 


success  :  out  integer  }  ; 


FROCETURE    dl_se5rrent    (    init    :    in    rl_pr  cce5S_def ;    success    : 

out    int  eger    ) i 


FRCCEDURE  rrk_5egment  (  init  :  in  rl_prcces  5_def ; 

mentor   :  in  inte.^er? 
entrx    : 
numter   : 
mode 
success  : 


in  integer; 
in  integer; 
in  seg_access_t>"pe; 

out  integer  ) ; 


FRCCEDURE  rrake_know_Sync  (  init  ;  in  rl_  process_def ; 

ch_para  :  ir  rl_T)arameters; 
ch_cla5S  :  in  access_clas5; 
ch_active  :  in  integer; 
ch_user_5ync  :  cut  users_act i ve ; 
success    :  out  integer); 

PROCEDURE  termiT]ate_synchr_seg  (irit  :  in  r  l_pr  ocess_def  ; 

cb_para  ;  in  rl_parameters ; 
ch_class  :  in  access_class; 
success    :  out  integer"); 

PROCEDURE  fill_init(  init  :  in  rl_pr ccess_def ; 

ch_init  :  out  rl_proce5S_def; 
ch_resource  :  in  chill _res  cj  rre  ; 
ch_acces5  :  in  level_re('or'i  )  ; 

PROCEDURE  cr_prcces5(  init  :  in  r l_proce55_def ; 

ch_para   :  in  rl_parame ters  ; 
ch  access  :  in  level  record; 


ie3 


prcces      :    ir    inte^ert 
ch_resource      :    in    chi ld_re5 ource ; 
synchr_seer    :    in    integer; 
success    ;    cut    integer); 


IHl 


prcce  ; 
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APPENDIX  F  -  SERVICE  ROUTINES  AND  ADDITIONAL  DATA  STRUCTURE 

This  appendix  contains  the  procedures  and  functions  used  by 
the  application  programs  related  to  execution  of  I/O  operations.  It  also  contains 
additional  data  structures  necessary  to  run  specific  application  programs 
(parameters,  record's  description,  constants,  etc.).  The  program  is  "Files"  and  is 
composed  of  two  modules.  "FILES. LIB"  (contains  the  specifications  of  records, 
functions  and  procedures  used)  and  "FILES. PKG"  (contains  the  code  developed 
for  each  procedure  or  function). 
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WITH  a^ate,  a^atej,  arl ,  alit,  alitj,  strlit,  util; 

PACKAGE  BCL^  files  IS 

USE  a^ate,  a^alej,    arl,  alit,  alilj,  strlit,  utii; 

STriO_W  :  CONSTANT  integer  :=  i; 
ST!:iC  R  :  CONSTANT  integer  :=  25 


FROCIDUEF  t24_f rn_integer(  in_val  :  in  integer; 

t24_val  :  out  t24_tyce  )I3 

Routine  to  convert  an  integer  into  a 
P24_type  variable  (  Z-tytes  ) 

BIG  IN 

t.24_val."byte2  :=  tyte(  ?  ); 

b24_val .tytel  :=  hi(  in_val  ); 

124  val.bytee  :=  lo{  in  val  ); 
FND  t24'frr  integer; 


FRCCIDURF  put_ln  (  Idev  :  in  integer; 

w_class  :  in  acce5s_class; 
str  :  instring  )  IS 

put  a  string  on  device  Idev  with  cr  and  If 

out_1:uf  :  strir.gf  82  )  ; 

success  :  integer; 

wt_sio  :  wt_seQ _st ruct ; 

size_str  :  integer; 

CR  :  CONSTANT  integer  :=  13; 

L7  :  CONSTANT  integer  :=  Ifl; 


BEGIN 
ou 
si 
cu 
ou 
wt 
wt 
wt 
wt 
wt 
wr 

END  pu 


t_tu 
ze_s 
t_tu 
t_tu 
_si  0 
_sio 
_si  0 
_sio 
_si  0 
ite_ 
t  In 


f  : 

tr 
f  : 
f  : 
.de 
.da 
.da 

.CO 

.cl 

seq 


=  str; 

:=  length(  str  ); 

=  cut_tuf  &  chdr_to_str{  character 'val ( 

=  out_tuf  &  char_to_str(  charac te r ' val ( 

vice  :=  Idev; 

ta_off    :=   out.buf 'ADDRESS    +    i; 

ta_seg    ;=  get_ss ( ) ; 

unt    :=    5ize_str    +   2; 

ass    :=   w_class; 

uentiaK    wt    sic,    success    ); 


CR 
LF 


)) 


PR0C5DURE  tlk_scr  (  Idev  :  in  integer; 

w_class  :  in  access_class ; 
str  :  in  string  )  IS 
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tlank  the  screen  and  put  the  cursor  in  the 
first  position 


out_tuf 

success 
w t_sio  : 
size_str 
ESC  : 

E 

EIGIN 

GU 

si 
ou 
ou 
wt 
wt 
wt 
wt 
wt 
wr 
11 


strin^v  82  ) ; 

i  n  t  e  i?  e  r ; 

wt _5eG  _5truc t ; 

:  integer; 

CONSTANT  integer 

CONSTANT  integer 


27; 

45; 


END 


t_tu 
ze_s 

t_tu 
t_tu 
_sio 
_si  0 
_sio 
_si  0 
_sio 
ite_ 
K  sc 


f  :  = 
tr  :  = 
f  :  = 
f  :  = 
.devi 
.data 
.data 
.  coun 
.  cl  as 
seque 
r; 


str; 

length (  str 
out_'buf  S.  char_tc_5tr(  charac  ter  '  val  ( 
cut_ 
ce  : 

off 


tuf  S.  char 

=  Idev; 
:=  cut_"buf' ADDRESS 
_seg  : =  get  _  ss (  ) ; 
t  :=  sizp_str  +  2; 
s  : =  w_cl ass ; 
ntiaK  wt_sio,  success  ); 


to_str(  character 'val ( 
+  i; 


ESC 

E  )); 


\  ^  . 
/■  /  ' 


PROCEDURE  get_5tr  (  Idev  :  in  integer; 

r_class  :  out  acce5S_class; 
str  ;  out  string  )  IS 


get 
in_tuf 
success 
rd_sic  : 
rd_ret  : 
size  str 


a  string  frorr  device  Idev. 

string'  82  ); 

integer; 
rd_seq  _struc t ; 
rd_seq_r8turn; 
;  integer; 


BEGIN 
rd 


END 


_sio.data_off  :=  in_tuf 'ADDRESS  +  i; 
rd_sio. device  :=  Idev; 
rd_si o.data_ seg  :=  get_ss(); 
read_sequential (  rd_sio,  rd_ret,  success  ); 
in_'buf(  0  )  :=  character 'val  (  rd_rst. count 
str  :=  in_tuf; 
r_class  :=  rd_ret  .cl ass ; 
get  str; 


PROCEDURE  put  str 


Idev  :  in  integer; 
w_class  :  in  access_class; 
str  :  in  s  tring  )  IS 


le? 


put  a  5trin,s;  or.  device  Idev 


out_luf 
success 
wt  _sic  : 
size  s  tr 


string; 
integer* 
wt_seq_struct; 

:  integer; 


EEaiN 

out_luf  :=  str; 

size_str    ;=    length(    str    ); 

wt_si 0  .device    :=    Idev; 

wt_5io.data_off    :=    out _tuf' ADERESS    + 

wt_sio .data_seg    :=  get_ss(;; 

wt_sio. count    :=    size_str; 

wt_sio. class    :=  w_class; 

write_sequential(  wt  sic,  success  ); 
END  put_str; 


i; 


PROCIDURI  put  iec(  Idev  :    in  integer; 


w  _  c  1  e  s  s 
dval  :  i 


in  acce55_cless; 
integer  )~IS 


put  the  string  equivalent  cf  a  integer  on  the  terminal 
screen. 

out_tuf:string(lf^); 

PIG  IN 

out_tuf  :=  Int_to_str(  dval  ); 

put_str(  Idev,  w_class,  cut_'tuf  ); 
F^E  put_dec; 


FP.OCEDUF.E  nut_succ(  in_str  :  in  string; 

dec_val  :  in  integer; 

w_cla5S  :  in  access_class  )  IS 

print  a  string  and  an  integer  on  device  attached  i- 
slot  STEIC_V  (should  te  a  serial  terminal). 

BEGIN 

put_str{  STEIO_'*,  w_class,  in_str  ); 

put_dec(  STlIO_W,  w_clas5,  dec_val  ); 

put_ln(  STEIO_¥,  w_class,  ""  ); 
ENE  put_succ; 
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FUNCTION  get_input(  eco  :  in  tocleei]; 

rd_cldss  :  in  access_cla5S  )    RETURN  string  IS 

Gets  an  input  strinis;  from  the  terminal  and  echoes  the 
input  if  the  echo  option  is  on.  It  also  converts  all  the 
input  to  lower  case 


constants 
STEIO_R  :  CONSTANT  integer 
STI}IO_'A  :  CONSTANT  integer 

rd_str  :  string; 
ind     :  integer; 


values 
inp_ch 
w_class 

BEGIN 


0; 
1; 


i  nteger ; 

string(l); 

:  acce5S_cl ass; end_input  r  coclean; 


w_class    :=  rd_class; 

end  input  :=  false; 

ind"      ;.=   i; 

rd_str  :=  ""; 

while  not  end_input  LOO? 

get_str(STriO  H,  w  class,  inp_ch); 
if  inp_ch(l)  In  'A'..'Z'  then 
inp_ch(l)  := 

char5cter'val(character'pos(inp_ch(l);+32}; 
end  if; 
if  (  character 'pos (inp_ch (1 )  )  =  13  )     then 

end_input  :=  true; 
else 

if  eco  then 

put_str(STDIO_W ,  rd_clas5,  inp_ch  ): 
ENE  ie; 

rd_str  :=  insert(  inp_ch,  rd_str,  ind  ); 
ind  :=  ind  +  i; 
end  if; 
end  loop; 
RETURN  rd  str; 


ENE  get_input; 

PROCEDURE  attarh_tew(  IO_PORT  :  in  integer; 

LEEV  :  in  integer)  13 

attach  serial  port  for  writing. 
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roce 

w_class 

success 


attach _struct; 
access_class; 

integer; 


BEGIN 


rrode 
mode 
node 
mode 
mode 
mode 
mode. 


dev_rarre 
si  ow_rec 
si  ow_rec 
si  cw_rec 
si  ow_rec 
si  ow_rec 
sicw  rec , 


:=   Slow. 

dev_nurr    :  =   i  o_port  ; 
dev_t,ype    •=   ic; 
dev    id    :=   LDEV; 
rrrl~:=   "byteC    16#?4r# 
mr2    :=    ■byte(    ie#03E# 
io  mode    :=   asrt    rtsJ 


); 
); 


at tach_device(  mode,  success  ); 

END  attach_tew; 

PROCEDURE  attach_tex-(  IC_POHT  :  in  integer! 

LpiV  :  in  integer)  IS 

—   attach  serial  rort  for  reading. 


mode_r 

w_class 

success 


at  tacn_s truct ; 
acce  ss_cla5s; 
integer; 


EEGIiM 


mode_ 

_r 

.dev_name 

• 
• 

mode] 

.sicr_rec 

.d 

mode_ 

_r 

.  si  or_rec 

mode_ 

T 

.  sicr_rec 

.d 

mode_ 

.r 

.  si  or_rec 

.m 

mode" 

_r 

.sior'rec 

.m 

mode_ 

_r 

.  sicr_rec 

.  i 

mode_ 

r 

.  si  cr_rec 

.d 

ri0de_ 

_r 

.  sior_rec 

.d 

mode' 

_r 

.  sior_rec 

.m 

attach 

device(  mo 

=    sior; 

ev_num    :=   io_]:ort; 

ev_type    :=    io; 

ev_id     :=   LTEV; 

rl     :=    tyte(    16#'24Di^    )  ; 

r2    :=    tytev    16^03E^    ) ; 

o_mode    :=    asrt_dtr; 

elim_active  ;=  FA.L3E; 

elimiter  :-  lytei    13  ) ; 

aximum  :=  i; 

—  only  reads  one  character  at 

de  r ,  success  ) ; 


a  time  . 


END  attach  ter; 


PROCEDURE  load_param {ini t  :  in  rl_process_def ; 

ch_para  :  out  rl_param)  IS 


Produces  a  tatle  of  parameters  with  informatiDn  needed 
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ty  the  R'dir  application  prcgrarr  (segnent  nurter,  entry, 
nent cr ) . 


INITIAL   :  CCNSTAKT  integer 
NI7.T_NUMB5H_FRII   :  CONSTANT 
CH  SYNCHR  f^ENTOR   :  CONSTANT 


=  "^  ■ 


i; 

integer 

integer 


=  40; 
=  44; 


index  ;  integer; 
next_segment  :  integer; 
data_nurriber  :  integer; 
ch_-carar   :  r  l_pararr!e  tersj 
usr_level  :  level_record  ; 
synchr_chld  :  integer; 


PEG  IN 
next 
data 

sync 

inde 
vhil 
ch 
ch 
ne 
ch 
ne 
ch 
ch 
ch 
ch 
ch 
ch 
da 
if 


grren  t 


_se 
_nu 
hr  chid 


rrter 


el 


EN 
ch 
in 
ENE 


X 

e  i 
_pa 

xt_ 

_P2 

^^_ 

_pa 
_p2 

_P3 

_Pa 

_P3 

_pa 

ta_ 

in 

ch 

ch 

sy 

ch 

sy 

se 

ch 

ch 

ch 

C  I 

_pa 

dex 

LOO 


ndex  < 
rarr.ent 
ram . men 
segmer  t 
ram .  seg 
segmen  t 
ram .  seg 
r  a  r  .  e  n  t 
ram .men 
ram .en  t 
rami .  men 
ram . seg 
numter 
dex  <  4 
_param . 
_param . 
nchr_ch 
_param . 
nchr  ch 


-INI 
NEIT 
CH_5 

=  1; 
5  LOO 
ry  _  s  t 
tor_s 

:=  n 
_numt 

:=  n 
_numh 
ry_c  3 
t  or_c 
ry_da 
tor_d 
_numh 
:=  da 

then 
synch 
synch 
Id  :  = 
synch 
Id  :  = 


tial; 
_nu^ber_free; 

YNCER_rENTOR  -^  i; 
—  next 


segment  availatle 


P 

ack  :=  index; 

tack    :=    initial; 

ext_segmert  -^  i; 

er_stack  :=  nex t_segmen t ; 

ext_segment  +  i; 

er_code  :=  next_segmer t ; 

de  :=  index  +  6; 

ode  :=  init  .  ini tial_seg(2  ) ; 

ta  :=  index  +  4; 

ata  :=  INITIAL; 

er_data  :=  dat  a_num'ber  ; 

ta  numter  +  i; 


r_chld_men tor 
r_chld_stack 

synchr_chld  ■ 
r_chld  _dat a 

synchr_chld  • 


_Daram  .synchr_chld_ment or 
_ pa  ram.  synchr_chld_stack 
_pcram.5ynchr_chld_data 

e; 

ra(irdex)  r=  ch_param; 
:  =  index  -r   1 ; 

p; 


:=  ck_synchh_me\tor; 

:=   synchr_chld; 

1; 
:=  synchr_chld; 

1; 

:=  2; 
:=  0; 

:=  0; 


END  load_param; 


111 


FROCZCURE  load_access_clc5S ( init  :  in  rl_proce 5S_def ; 

usr_dcces5  :~out  user_leyel  )  IS 

Produces  a  tatle  with  the  security  access  level  depen- 
ding on  the  user  level 


usr  level 


level  record; 


BEGIN 

usr_level  .rrin.compromise.int2 
usr_level.min .comprcmise.intl 
usr_level.min. integrity .intC 
usr_level.min.inte^rity.intl 
usr_level  .max. com promise. intB 
usr_level  .max.compromise .intl 
usr_level  .max.  integer  it  y.int? 
usr_level. max. inteejrity. intl 
usr  access'TOF  SECRET)  :=  usr 


■■  0; 

=  ?; 

■  0; 

■■  21504; 

■■  e; 

■  0; 

■  (?; 

level; 


—  ^  • 

=   0; 
=  •?; 

=  21504; 
=  4; 

_   ra  • 

—  t  1 

=  0; 

=  21504; 


ei; 


usr_level.min.ccmpromise.int0 
usr_level.min.compromise.intl 
usr_level  .mir'.inte^rity.int0 
usr_level.min.integrity.iatl 
usr_  level. max.  comprorrise.  into 
usr_level.max.compromise.intt 
usr_level.max.integrity.int0 
usr  level  .max . integrity . in tl 
usr'accessfCONEIPENTIAL)  :=  usr 


rr    • 

c  1 
0; 

^  0; 
21504; 

2 ; 

ft . 

t' » 

■■   0; 
21504; 
level ; 


usr_ level .min .compromise .int0 
usr_level  .min.compromise.intl 
usr_level.min. integrity . i  n  t0 
usr_ level  .min .integrity.intl 
usr_level  .max.compromise  .intv'^ 
usr_level. max. compromise. intl 
usr_ level  .max  .integrity .int0 
usr_level. max. integrity. intl 
usr  access(UNCLASSIFIED)  :=  usr 


=  0; 
=  0; 
=  0; 
-  21504; 

—  f~^  * 

-  VO'  ? 

=  0; 

=  0; 

=  21504; 
level; 
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IMD  load  access  class; 


PP.OCEDUFJ    lcad_pararr.l(init    :    in   rl_prccess_def ; 

ch_pararr;    :    out    rl_pararre ters    )    IS 

Produces   a    tatle    of    parameters    with    irforrration    needed 
"by    the   User   Handler 


MENTOR 


:    CONSTANT    integer 


i; 


—   always    1 


•.'^'? 


BEGIN 

ch_pararr  .en  try_stack    :=   i; 

ch_pa  rarr. .  ren  tor_stacx    :=   MENTOR; 

ch_paran  .  seg_nuiT'ter_stack    :=   32; 

ch_pe  rarr  .  seg_numler_code    :=  33; 

ch_parar . er try_ccde      ;=    4; 

ch_pa  rarr  .rr;Fn  tcr_code    :=    in  i  t .  i  ni  tial_seg(l  )  ; 

ck_pcran  .  en  try_data    :=    2', 

ch_pararr  .rrentor_data    :=   MENTOR; 

ch_parar; .  se2_nurrter_da  ta    :-   34; 

ENE    load_pararri; 

PROCEDURE    loaa_child_active 

(usr_active    :    out    users_dc t i ve  )    IS 

Initializes    the   Active    User    record    to   FALSE.    It    lets 
CCF    load    the   Active   User    segments   each    time   a    false 
record    is    found 


index    :    integer; 

BEGI."^ 

index    :  =    1 ; 

while  index  <  3  LOOP 

usr_activp( index ) .active  :=  FALSE' 

usr_act ive ( index ). seg_data  ;=  0; 

U5r_active( index) .seg_stack  :=  ?; 

usr_active ( index )  .evc_data  :-   2; 

usr_active( index ) .evc_stack  :=  0; 

index  :=  index  +  i; 
end  loop; 

END  1 oad_child_active; 

PROCEDURE  looic_f  or_level  (usemame  :  in  string; 

password  :  in  string; 


113 


ch_acce5s 
ch  class 


in   user_level  » 
out      dcces s   class)    IS 


Sirruldtes    the   lo^on    process,    loading   the   access    class    cf 
the  user   deDendin^:   on    the   Usernarne   and    Pasword 


BE^IN 


if   password   = 

ch_class  := 
elsif   password 

ch_class  := 
ELSIF    password 

ch_class  := 
FLSF 

ch  class  := 

END  if; 


falconl   ther 
ch^access  ( 1 )  .rr,ax  J 
=  "falcon"  then 
ch^access  (2  )  .rrax  ; 
=  "secret"  then 
ch_acce5S (3 ) .rar \ 

ch  access (4  )  .max; 


END  lock_f cr_levei; 

FRCCEDURF  initialize  tallesfsepj  tatle  :  out  files  data; 


seie  head 


ut  segrent  neaaer)  I 


Initializes  the  internal  tat]  es  that  will  sin'ulate  the 
automatic  creation  of  sefsmerts  numters  usin??  the  Lri 
—   tatle 


index 
w  class 


i  nteger; 
access  class; 


PEGI 

V 

w 
w 
w 
s 

5 

s 
s 
s 
s 

s 


_c  lass  .  inte^ri  ty . int0 
_class.integrit,Y  .intl 
_class  .corrpromise.intl 
_class.rorT:prcrise.int2' 
eg_head.rraT_files_stored 
e^_head.rext_avail_seg 
eg_head .nex t_avai l_ent 
e^_head.next_avail_men 
eg_head.max_open_se^ 
eg_head .mcx_open_ent 
eg   head. max    open   men 


0; 


=  e; 

:=  0; 

:=  e; 

j    :  - 

0; 

:  = 

IMITIAL 

ER^E 

SEa^lSNT 

;  = 

INITIAL' 

"free" 

'entry; 

:  — 

INITIAL 

"free" 

"men  To r; 

:  = 

INITIAL' 

frle 

S EG KENT 

:  = 

INITIAl" 

'free 

'entry  ; 

;  = 

INITIAL' 

'free 

'mentor; 

initialization  of  array  that  holds  files  information 

index  :=  0; 

while  index  <  MAX  NUMEEF  OF  FILES  +  1  LOOP 


se g_ tatle find ex ).nurter 
seg  tatlef index) .en trys 


:=  0; 

:=  z; 


1 
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.nentor     '-   ^.}. 

.  f i le  _name 

.acces5_cla 

.  next_avail_5e5? 

.  next  _ava  i  l_eri  t 

.next  avail  rren 


w_clas5; 

=  INITIAL_?REI  segment; 

=  initial  frfe"i\?ry  ; 
=  initial'ereI'I'mentor; 


seg_tatle( index 
se^_tatle( index 
seg_ta'ble(  index 
5e^_tatle ' index 
seg_table ( index 
ses:_tat'le(  index 
index  :=  index  +  i; 

end  loop; 

END    ini tialize_tables ; 

FUNCTION    Cxheck_if_exists_f ile_narre 

(seg_table    :    in    files    data; 

file_narre    :    in    string!   RETURN    boolean    IS 

check    if    file   name   declared    in    input    comrrard   exists    or 
does    not 


index 
an  swer 


:    intep:er; 
:    "boolean; 


BEGIN 

index    :=   2', 

answer    :=   EALSE; 

while    index    <   MAX_NUV'BER_0?_EI  LES 

if    seg_table  (  index  ).  file_narre   ^ 

answer      :=   TRUE; 

RETURN  answer; 
else 

index  :=  index  +  i; 
end  if; 


1  LOOP 


file  rane  then 


END  loop; 

RETURN  answer; 

FNL   check_if _exi5ts_f  ile_narre  ; 

PROCEDURE    convert  (  ch_in    :    in      inpu  t_nie5sage; 

w_class      :    in   access_class; 
ch_out         :    out    corrand-_line )    IS 

this    procedure    assembles    the    commad    line   usinj^    the    input 
message    typed   by    the   user 


index 
index  1 
temp 
inp    ch 


:  integer; 

:  integer; 

:  string; 

:  string(l); 
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BEGIN 


terrp  :  = 

index  : =  1 ; 

ir.dexl  :=  i; 

while  ( ( index  <=  40  ) 

and  (index  <=  length (ch_i n . input_ one )) )  LOOP 


if  ( ( ch_in . input_cne ( i ndex )  in  'd'..'z   )  or 
( ch_ in. input _ one ( index  )  in  '0'..'9'  ))  then 
temp(indexl)  :=  ch_in . input _one ( index ) ; 
indexl  :  =  indexl  -^  1  : 
else 

if  ( ( cheracter 'po 5 ( ch_in  .input_ore ( index ) )  =  32) 

and 
(  index  /=  1  )  and 

(character 'pes ( ch_in . input _one { index-1 ) )    /=   32)) 

ther 
terrp  (  indexl )     :=   ch_in  .  input_one(  index  }  ; 
indexl    :=   indexl    ^   i; 
else 
if 
( (character 'pc5( rh_ i n .i nput_one ( index ) )    -   94) 

or 
( character 'pcs( ch_in  .input_one (index ] )    =   125;) 
indexl    :=   indexl   -    i; 
terrpdndexl )    :=    '    '; 
end    if; 
end    if; 
end    if; 

index  :=  index  -^  i; 
end    LCCP; 


load    corrrrand   line 


ch_out .  conrrand    :  = 
c h_ out. file_ nan el    := 
ch_cut . f ile_name2    := 
ch_out.corr.n'and_class 
index    :=i; 
indexl    :=    i; 


=  ch_in  .  input_class ; 


loop  to  fill  command 

while  (( character 'pos( temp( index ) )  /=  32)  and 
(  indexl  <  9  ))  LOOP 

ch_out . c ommand( indexl )  :=  tepp(index); 
indexl  :=  indexl  +  i; 
index   :=  index   +  i; 
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end   loop; 

—  loop    to    fill    filenarrie   1 

index  :=  irdex  +  1*. 
indexl  :=  i; 

while  ( (character 'pos ( temp (irdex ) )  /=  32)     and 
(indexl  <  9  )  )  LOOP 

ch_out .  file_narel  (  indexl )  :=  terrp  (i  ndex  ) ; 
indexl  :=  indexl  +  i; 
index   :=  index  +  i; 
end  loop; 

—  loop  to  fill  filenarre  2 

index    :=    index    -^    i; 
indexl    :=   i; 


while    (( cha rdc ten 'pos( terp ( index ) )    /=   32) 
(indexl   <   9    ))    LOOP 

ch_out  .file_name2  (indexl )    :=    terrp  (index  } ; 
indexl    :-    indexl    +    i; 
index      :=    index      +    i; 
end   LOCP; 


C  :1  iwt 


SNE  convert; 
INE  files; 
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WITH  agate,  a^atej,  arl,  alit,  alilj,  strlit,  utii; 

PACKAGI   files  IS 

USE  agate,  agatej,  arl,  alit,  alitj,  strlit,  utii; 


max  users 

maxIfroc 

max_linss 

MAX_NU^'EER_OF_FILES 

MAX_INFUT_CHSAR 

INITIAL_FRiE_SEGMENT 

INITIAL_FRIE  ENTRY 

INITIAL_ER5E>ENT0R 

IAST_FREE_SEGMrNT 

LAST_EREE_ENTRi; 

LAST_FEEE_r'ENTOR 

SEGMENT_LENGTH 

MAX_LEVELS 

TOF_SECRrT 
S''*"CRET 

con'fidential 
unclassified 


CONSTANT 
CONSTANT 
CONSTANT 

CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 

CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 


integer 
i  n teger 
integer 

—  rrax 
integer 
in  teger 
integer 
integer 
in  teger 
integer 
in  teger 
integer 
in t  eger 
in  tege  r 

—  rrax 
integer 
integer 
in  teger 
integer 


4; 
100; 

record  5 
21; 
50; 
31; 
0: 
25; 
51; 
11; 
30; 
e008; 
4; 

security 
1; 

2; 

'x  • 

>->  • 

4; 


for  file 


levels 


SUBTYPE  segrent_nurr>er  IS  integer  RANGE  31.. 51; 
SUBTYPE  entry_nurrter  IS  integer  RANGE  0..11; 
SUBTYPE  rentor  nurrter  IS  integer  RANGE  25.. 30; 


TYPE  r 
ent 
men 
seg 
ent 
men 
seg 
ent 
rren 
seg 
evn 
evn 
syn 
syn 
syn 

END  RE 


l_i:ararnet 

ry_starV: 

tor_stack 

_nurter_s 

ry_c  ode 

t  cr_code 

_num'ber_c 

ry_data 

t  or_data 

_  nu  m  "b  e  r  _  ^. 

_count 

_count_da 

rhr_chld_ 

chr _chld_ 

chr_chld_ 

cord; 


ers  IS  RECORD 
:  integer; 
:  integer; 

tack  :  integer; 
integer 
integer 

ode  :  integer 
integer 
integer 

ata  :  integer 
integer 

ta   :  integer 

[renter    :    integer; 

stack      :    integer; 

data        :    integer; 


TYPE    rl_paran    IS    ARRAY    (l..MAX_FROC    )    of    r l_parane te rs ; 
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TYFI  data_record     IS  EECOHD 

datal     :  strin^(50); 
T^JI  ricchd; 

TYPE  data  file  I?  ARRAY  (l..^AX  LIfsES)  cf  data  record; 


TYPE  5eg_info 
nurt er 
e  n  t  r  y  s 
ment  or 
f  ile_r.ame 
acce55_cla 
next_ai'eil_seg 
next _avail_er  t 

next_avail_rren 
ENE  recgre; 

TYPE  se^n-e!>t_header  IS  RECORI 


IS    RICORE 

se^nen  t_nuin"ber; 
en  try_numter ; 
ment  or_nun"ter ; 
string(S)  ; 
:    access_rlass J 
sef^men  t  _nunter ; 
en try_numler  5 
mentor    nurter; 


max_f il es_  5  t  ored 
next_avail_s'?,s 
n  ex t  _avail _en  t 
nex  t_ava  il _ren 
raT_oi:en_sefr 
rrax_open_en  t 
max_open_men 
Ei\"E  reccre; 


in  te^er; 
5egren  t_numter  J 
en  t  ry_nurr  cer  » 
ment  or_nun'ber  I 
se^r^en  t  _numl:er  i 
en  t  ry_niirr"ber ; 
mentor    numterJ 


TYPE  input_messa^e 
input_one 
input_  re  su 1 1 
ir.put_cla5S 

EN!}  record; 


IS  RECORE 

:  stri-^gvS?')  ; 

:  stri'"^(ce); 
:  access  class; 


TYPE  romcrd_line 
c  orrand 
f ile_Tdrel 
f  i  le_narie?. 
command_cl ass 
result 

E.NE  RECCRE; 


IS  RECORE 


strir^(£^; 
string(P J ; 

strins(e); 
access_class ; 
St  ring  (5'?)  ; 


TYPE  segment_data    IS  RECORE 

segm_info  :  data_file; 

segm_class  :  access  class; 

ENE  record; 

TYPE  file5_data  IS  ARRAY  (?.  .^^AX_^U^'PER_OE_E  ILES  ;  of 

se2;_inf  0 ; 

TYPE  level  reccrd  IS  RECORE 
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mn 
max 
ENE  p.ecore; 


:  acces£_class J 
:  access  class? 


TY?r  user_level  IS  ARRAY  ( e  .  .MAX_LLVILS )  of  le vel_record ; 
TYPE  user  synchro   IS  RECORD 


active 

seg_data 

se^_stacic 

evc_data 

eYc_stack 

END  record; 


toolear. ; 

inte^e  r ; 
integer; 
integer ; 
integer ; 


TYPE  users_active   IS  ARRAY  (1  .  .NAX_USZRS ;  of  user_synchro ; 
TYPE  child  resource  IS  RECORD 


mercry 
I,rocesses 
s  egpent s 

END  record; 


integer ; 
in  teeer ; 
inte^^er; 


PRCCELURE  t24_f  rrn_in  tef^er  (  in_val  :  in  integer: 

t24  val  :  out  124  type  ); 


PRCCELURE  put_ln  (  Idev  :  in  integer; 

w_class  :  in  acces5_cl3ss; 
str  :  in  string  ); 


PROCEDURE  tlk_scr  (  Idev  :  in  integer; 

w_rlass    :    ir    acces5_class; 
str    :    in    string    ); 


PROCEDURE  get_str  (  Idev  :  in  integer; 

r_class  :  out  access_class; 
str  :  out  string  ); 


PROCEDURE  put_str  (  Idev  :  in  integer; 

w_class  :  in  access_class; 
str  :  in  string  ); 

PROCEDURE  put_dec(  Idev  :  in  integer; 

w_class  :  in  access_class; 
dval  :  in  integer  )  ; 

PROCEDURE  put_succ(  in_str  :  in  string; 
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dec_vcl  :  in  integer! 
w_cldS5  :  in  acces5_class  )» 

FUNCTION  ^et_input^  eco   :  in  tcclean; 

rd_class  :  in  cccess_cla5s  )  ?.ITUR'^I  strings? 

PROCIDURI  attarh_tew(  IO_PORT  :  in  inte,^er; 

LDIV  :  in  integer); 

PROCEDURE  attach_ter(  IO_FOPT  :  in  integer; 

LDEV  :  in  intes;er)  ; 

PROCEDURE  load_param(  init  :  in  r l_process_def ; 

ch_paraiT  :  out  rl_param)  ; 

PROCEDURE  load_access_class '  init  :  in  ri_process_G ef ; 

usr  access  :  out  user  level;; 


PRCCEDURI  load_p£ranl(init  :  in  rl_proce S5_def ; 

ch_pararr;  :  out  rl_paraneters  ); 

PROCEDURE  lcad_child_act ive (act iv_usr  :  out  U5£rs_a r ti v?  )  ; 

PROCEDURE  lock_f  or_level  (usernare  :  in  string;; 

password  :  in  string; 
ch_acce5S  :  in  U5er_levei; 
ch_clas5  :  out  access_cl as s ) ; 

PROCEDURE  initiali2e_tatles (seg_tatle  :  out  files_data; 

seg_head   :  cut  segrren  t  _hecder  ) ; 

FUNCTION  check_if_exi5ts_f ile_nane(seg_tatle  :  in  files_data; 

file_narr,8  :  in  string)  RETURN  tooleen* 

PROCEDURE  convert  (  ch_  in  :  i  r.  input  _rres  sage  ; 

w_class  :  in  acces s_class ; 
ch_out  :  out  corand_line  ); 

END  files; 
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APPENDIX  G  -  SYSGEN  SUBMIT  FILE  (SSB) 

This  appendix  contains  the  description  of  the  Sysgen  Submit 
File  used  to  sysgen  the  entire  system,  the  commiands  used  are  : 


bs:ld3.cmd 

ksrkO.cmd 

ks:kl.cmd 

ks:k2.cmd 

cs:vlloader.cmd;2; 

ds:vilogin.cmd;2,10; 

ds:nv.ds;2,5: 

ds:nv.ds;5; 

ds:pnnain.cmd;5,0;t; 

ds:puserl.cm;d:5,7; 

ds:prchll.cmd;5,7.4: 

ds:puser2.cmd:5.8: 

ds:prchl2.cnQd;5,8,4: 

ds:puser3.cmd:5.9: 

ds:prchl3.cmd;5,9,4; 

ds:prbdos.cmd;5,10; 

ds:rltrap.cmd;6; 

end 
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